Laws of Software Engineering

by milanm081 on 4/21/2026, 11:04:56 AM

Comments

by: bakkerinho

> This site was paused as it reached its usage limits. Please contact the site owner for more information.Law 0: Fix infra.

4/21/2026, 1:20:13 PM

by: Aaargh20318

I’m missing Curly’s Law: <a href="https://blog.codinghorror.com/curlys-law-do-one-thing/" rel="nofollow">https://blog.codinghorror.com/curlys-law-do-one-thing/</a>“A variable should mean one thing, and one thing only. It should not mean one thing in one circumstance, and carry a different value from a different domain some other time. It should not mean two things at once. It must not be both a floor polish and a dessert topping. It should mean One Thing, and should mean it all of the time.”

4/21/2026, 1:10:55 PM

by: arnorhs

Since the site is down, you can use the archive.org link:<a href="https://web.archive.org/web/20260421113202/https://lawsofsoftwareengineering.com/" rel="nofollow">https://web.archive.org/web/20260421113202/https://lawsofsof...</a>

4/21/2026, 1:39:56 PM

by: conartist6

Remember that these "laws" contain so many internal contradictions that when they're all listed out like this, you can just pick one that justifies what you want to justify. The hard part is knowing which law break when, and why

4/21/2026, 12:13:08 PM

by: fenomas

Nice to have these all collected nicely and sharable. For the amusement of HN let me add one I've become known for at my current work, for saying to juniors who are overly worried about DRY:> Copy-paste is free; abstractions are expensive.edit: I should add, this is aimed at situations like when you need a new function that's very similar to one you already have, and juniors often assume it's bad to copy-paste so they add a parameter to the existing function so it abstracts both cases. And my point is: wait, consider the cost of the abstraction, are the two use cases likely to diverge later, do they have the same business owner, etc.

4/21/2026, 1:00:36 PM

by: RivieraKid

Not a law but a a design principle that I've found to be one of the most useful ones and also unknown:Structure code so that in an ideal case, removing a functionality should be as simple as deleting a directory or file.

4/21/2026, 12:37:18 PM

by: dataviz1000

I 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.[0]<a href="https://blog.codinghorror.com/boyds-law-of-iteration/" rel="nofollow">https://blog.codinghorror.com/boyds-law-of-iteration/</a>

4/21/2026, 12:01:47 PM

by: dgb23

I like this collection. It's nicely presented and at least at a glance it adds some useful context to each item.While browsing it, I of course found one that I disagree with:Testing Pyramid: <a href="https://lawsofsoftwareengineering.com/laws/testing-pyramid/" rel="nofollow">https://lawsofsoftwareengineering.com/laws/testing-pyramid/</a>I think this is backwards.Another commenter WillAdams has mentioned A Philosophy of Software Design (which should really be called A Set of Heuristics for Software Design) and one of the key concepts there are small (general) interfaces and deep implementations.A similar heuristic also comes up in Elements of Clojure (Zachary Tellman) as well, where he talks about "principled components and adaptive systems".The general idea: You should greatly care about the interfaces, where your stuff connects together and is used by others. The leverage of a component is inversely proportional to the size of that interface and proportional to the size of its implementation.I think the way that connects to testing is that architecturally granular tests (down the stack) is a bit like pouring molasses into the implementation, rather than focusing on what actually matters, which is what users care about: the interface.Now of course we as developers are the users of our own code, and we produce building blocks that we then use to compose entire programs. Having example tests for those building blocks is convenient and necessary to some degree.However, what I want to push back on is the implied idea of having to hack apart or keep apart pieces so we can test them with small tests (per method, function etc.) instead of taking the time to figure out what the surface areas should be and then testing those.If you need hyper granular tests while you're assembling pieces, then write them (or better: use a REPL if you can), but you don't need to keep them around once your code comes together and you start to design contracts and surface areas that can be used by you or others.

4/21/2026, 1:27:55 PM

by: netdevphoenix

"This site was paused as it reached its usage limits. Please contact the site owner for more information."I wish AWS/Azure had this functionality.

4/21/2026, 1:17:29 PM

by: dassh

Calling them 'laws' is always a bit of a stretch. They are more like useful heuristics. The real engineering part is knowing exactly when to break them.

4/21/2026, 1:01:57 PM

by: ozgrakkurt

For anyone reading this. Learn software engineering from people that do software engineering. Just read textbooks which are written by people that actually do things

4/21/2026, 12:06:18 PM

by: Sergey777

A lot of these “laws” seem obvious individually, but what’s interesting is how often we still ignore them in practice.Especially things like “every system grows more complex over time” — you can see it in almost any project after a few iterations.I think the real challenge isn’t knowing these laws, but designing systems that remain usable despite them.

4/21/2026, 1:04:05 PM

by: wesselbindt

Two of my main CAP theorem pet peeves happen on this page:- Not realizing it's a very concrete theorem applicable in a very narrow theoretical situation, and that its value lies not in the statement itself but in the way of thinking that goes into the proof.- Stating it as "pick any two". You cannot pick CA. Under the conditions of the CAP theorem it is immediately obvious that CA implies you have exactly one node. And guess what, then you have P too, because there's no way to partition a single node.A much more usable statement (which is not a theorem but a rule of thumb) is: there is often a tradeoff between consistency and availability.

4/21/2026, 1:08:09 PM

by: tmoertel

One that is missing is Ousterhout’s rule for decomposing complexity:<pre><code> complexity(system) = sum(complexity(component) * time_spent_working_in(component) for component in system). </code></pre> The rule suggests that encapsulating complexity (e.g., in stable libraries that you never have to revisit) is equivalent to eliminating that complexity.

4/21/2026, 12:03:16 PM

by: r0ze-at-hn

Love the details sub pages. Over 20 years I collected a little list of specific laws or really observations (<a href="https://metamagic.substack.com/p/software-laws" rel="nofollow">https://metamagic.substack.com/p/software-laws</a>) and thought about turning each into specific detailed blog posts, but it has been more fun chatting with other engineers, showing the page and watch as they scan the list and inevitably tell me a great story. For example I could do a full writeup on the math behind this one, but it is way more fun hearing the stories about the trying and failing to get second re-writes for code.9. Most software will get at most one major rewrite in its lifetime.

4/21/2026, 12:21:03 PM

by: bpavuk

> This site was paused as it reached its usage limits. Please contact the site owner for more information.ha, someone needs to email Netlify...

4/21/2026, 1:17:44 PM

by: mojuba

> Get it working correctly first, then make it fast, then make it pretty.Or develop a skill to make it correct, fast and pretty in one or two approaches.

4/21/2026, 12:10:17 PM

by: Symmetry

On my laptop I have a yin-yang with DRY and YAGNI replacing the dots.

4/21/2026, 12:51:22 PM

by: WillAdams

Visual 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<a href="https://www.goodreads.com/en/book/show/39996759-a-philosophy-of-software-design" rel="nofollow">https://www.goodreads.com/en/book/show/39996759-a-philosophy...</a>(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.....

4/21/2026, 11:34:36 AM

by: tfrancisl

Remember, just because people repeated it so many times it made it to this list, does not mean its true. There may be some truth in most of these, but none of these are "Laws". They are aphorisms: punchy one liners with the intent to distill something so complex as human interaction and software design.

4/21/2026, 12:20:55 PM

by: serious_angel

Great! Do principles fit? If so, considering presence of "Bus Factor", I believe "Chesterton's Fence" should be listed, too.

4/21/2026, 12:39:48 PM

by: vpol

Is it not the same as <a href="https://github.com/dwmkerr/hacker-laws" rel="nofollow">https://github.com/dwmkerr/hacker-laws</a> ?

4/21/2026, 12:27:20 PM

by: bronlund

Pure gold :) I'm missing one though; "You can never underestimate an end user.".

4/21/2026, 12:51:11 PM

by: duc_minh

Is it just me seeing the following?Site not available This site was paused as it reached its usage limits. Please contact the site owner for more information.

4/21/2026, 1:16:33 PM

by: James_K

I feel that Postel's law probably holds up the worst out of these. While being liberal with the data you accept can seem good for the functioning of your own application, the broader social effect is negative. It promotes misconceptions about the standard into informal standards of their own to which new apps may be forced to conform. Ultimately being strict with the input data allowed can turn out better in the long run, not to mention be more secure.

4/21/2026, 1:05:25 PM

by: grahar64

Some 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.

4/21/2026, 11:30:41 AM

by: d--b

It's missing:> Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.<a href="https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule" rel="nofollow">https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule</a>

4/21/2026, 12:14:14 PM

by: IshKebab

Calling these "laws" is a really really bad idea.

4/21/2026, 12:11:33 PM

by: threepts

I believe there should be one more law here, telling you to not believe this baloney and spend your money on Claude tokens.

4/21/2026, 12:34:27 PM

by: _dain_

I have a lot of issues with this one:<a href="https://lawsofsoftwareengineering.com/laws/premature-optimization/" rel="nofollow">https://lawsofsoftwareengineering.com/laws/premature-optimiz...</a>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.

4/21/2026, 12:08:44 PM

by: milanm081

[dead]

4/21/2026, 11:04:56 AM

by: Antibabelic

Software engineering is voodoo masquerading as science. Most of these "laws" are just things some guys said and people thought "sounds sensible". When will we have "laws" that have been extensively tested experimentally in controlled conditions, or "laws" that will have you in jail for violating them? Like "you WILL be held responsible for compromised user data"?

4/21/2026, 12:23:08 PM

Hacker News Viewer

Top 20