Laws of Software Engineering
lawsofsoftwareengineering.com
Laws of Software Engineering
1–10 of 554 posts
Re: Laws of Software Engineering
#2For years, I kept notes on patterns I saw in software projects, architecture, planning, estimation, testing, scaling, and team design.
I pulled those notes into a browsable site with 56 laws, grouped into categories, with short explanations and separate pages for each one.
The goal was simple: put these ideas in one place, so when you want a quick refresher on Conway’s Law, Brooks’s Law, Gall’s Law, Hyrum’s Law, or Goodhart’s Law, you can find it fast.
I’m more interested in criticism than praise. Which laws are missing, which ones feel overstated, and which ones get misused most often in real work?
Re: Laws of Software Engineering
#3Some of these laws are like Gravity, inevitable things you can fight but will always exist e.g. increasing complexity. Some of them are laws that if you break people will yell at you or at least respect you less, e.g. leave it cleaner than when you found it.
Re: Laws of Software Engineering
#4Visual list of well-known aphorisms and so forth.
A couple are well-described/covered in books, e.g., Tesler's Law (Conservation of Complexity) is at the core of _A Philosophy of Software Design_ by John Ousterhout
https://www.goodreads.com/en/book/show/39996759-a-philosophy...
(and of course Brook's Law is from _The Mythical Man Month_)
Curious if folks have recommendations for books which are not as well-known which cover these, other than the _Laws of Software Engineering_ book which the site is an advertisement for.....
Re: Laws of Software Engineering
#5I did not see Boyd’s Law of Iteration [0]
"In analyzing complexity, fast iteration almost always produces better results than in-depth analysis."
Boyd invented the OODA loop.
Re: Laws of Software Engineering
#6Some of these laws are like Gravity, inevitable things you can fight but will always exist e.g. increasing complexity. Some of them are laws that if you break people will yell at you or at least respect you less, e.g. leave it cleaner than when you found it.
Lots of them are also only vaguely related to software engineering, e.g. Peter Principle.
It’s not a great list. The good old c2.com has many more, better ones.
Re: Laws of Software Engineering
#7One that is missing is Ousterhout’s rule for decomposing complexity:
complexity(system) =
sum(complexity(component) * time_spent_working_in(component)
for component in system).
Re: Laws of Software Engineering
#8One that is missing is Ousterhout’s rule for decomposing complexity: complexity(system) = sum(complexity(component) * time_spent_working_in(component) for component in system). The rule suggests that encapsulating complexity (e.g., in stable libraries that you never have to revisit) is equivalent to eliminating that complexity.
That’s not some kind of law, though. And I’m also not sure whether it even makes sense, complexity is not a function of time spent working on something.
Re: Laws of Software Engineering
#9For anyone reading this. Learn software engineering from people that do software engineering. Just read textbooks which are written by people that actually do things
Re: Laws of Software Engineering
#10I have a lot of issues with this one:
https://lawsofsoftwareengineering.com/laws/premature-optimiz...
It leaves out this part from Knuth:
>The improvement in speed from Example 2 to Example 2a is only about 12%, and many people would pronounce that insignificant. The conventional wisdom shared by many of today’s software engineers calls for ignoring efficiency in the small; but I believe this is simply an overreaction to the abuses they see being practiced by penny-wise- and-pound-foolish programmers, who can’t debug or maintain their “optimized” programs. In established engineering disciplines a 12% improvement, easily obtained, is never considered marginal; and I believe the same viewpoint should prevail in software engineering. Of course I wouldn’t bother making such optimizations on a one-shot job, but when it’s a question of preparing quality programs, I don’t want to restrict myself to tools that deny me such efficiencies.
Knuth thought an easy 12% was worth it, but most people who quote him would scoff at such efforts.
Moreover:
>Knuth’s Optimization Principle captures a fundamental trade-off in software engineering: performance improvements often increase complexity. Applying that trade-off before understanding where performance actually matters leads to unreadable systems.
I suppose there is a fundamental tradeoff somewhere, but that doesn't mean you're actually at the Pareto frontier, or anywhere close to it. In many cases, simpler code is faster, and fast code makes for simpler systems.
For example, you might write a slow program, so you buy a bunch more machines and scale horizontally. Now you have distributed systems problems, cache problems, lots more orchestration complexity. If you'd written it to be fast to begin with, you could have done it all on one box and had a much simpler architecture.
Most times I hear people say the "premature optimization" quote, it's just a thought-terminating cliche.