Laws of Software Engineering

by milanm081 • 3 months ago

1172 510 3 months ago

milanm0815• 3 months ago

For 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?

grahar64• 3 months ago

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.

stingraycharles2• 3 months ago

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.

layer83• 3 months ago

Physical laws vs human laws.

WillAdams2• 3 months ago

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

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

dataviz1000• 3 months ago

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]https://blog.codinghorror.com/boyds-law-of-iteration/

Silamoth3• 3 months ago

That’s such a good one! I wish more people understood this. It seems management and business types always want some upfront plan. And I get it, to an extent. But we’ve learned this isn’t a very effective way to build software. You can’t think of all possible problems ahead of time, especially the first time around. Refactoring to solve problems with a flexible architecture it better than designing yourself into a rigid architecture that can’t adapt as you learn the problem space.

devsda• 3 months ago

I think taking Boyd's law to the extreme is how some folks end up with sprints lasting 1 week or less.

computerdork5• 3 months ago

That is a good one, iterative development is in general superior to overly deliberate and overly careful development.

And what a great and very subtle example with the fighter jet control sticks. This reminds of a build time issue I once had. Yeah, way back in college, did really poorly on a final programming project, because didn't realize you were supposed to swap out a component they had you write with a mock component that was provided for you - hard to explain, but they wanted you to write this component to show you could, but once you did, you weren't supposed to use it, because it was extremely slow to build. So they also gave you a mock version to use when working on the code of your main system.

Using my full component killed my build time, as it took 10 minutes to build instead of a few seconds, and it was the one school programming project I couldn't finish before the deadline and was super stressful. Was a very painful lesson but ever since have always found ways to shorten my build times.

AnimalMuppet• 3 months ago

iterative development is in general superior to overly deliberate and overly careful development.

I reserve the right to become smarter as I learn stuff. That means that I reserve the right to produce better designs as I learn stuff. Want me to produce better designs? Let me learn stuff. Therefore, let me iterate a few times.

martinclayton• 3 months ago

This resonates with "the bitter lesson" somehow, interesting...

...On reading more it seems of use primarily in adversarial situations, so not-so-much resonant.

tmoertel3• 3 months ago

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

stingraycharles2• 3 months ago

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.

tmoertel3• 3 months ago

First, few of the laws on that site are actual laws in the physics or mathematics sense. They are more guiding principles.

complexity is not a function of time spent working on something.

But the complexity you observe is a function of your exposure to that complexity.

The notion of complexity exists to quantify the degree of struggle required to achieve some end. Ousterhout’s observation is that if you can move complexity into components far away from where you must do your work to achieve your ends, you no longer need to struggle with that complexity, and thus it effectively is not there anymore.

Brian_K_White• 3 months ago

It's showing that all the complexity in the components are someone else's problem. Your only complexity is your own top layer and your interface with the components.

CuriouslyC• 3 months ago

I think the intent is that if you can cleanly encapsulate some complexity so that people working on stuff that uses it don't have to understand anything beyond a simple interface, that complexity "doesn't exist" for all intents and purposes. Obviously this isn't universal, but a fair percentage of programmers these days don't understand the hardware they're programming against due to the layers of abstractions over them, so it's not crazy either.

someguyiguess4• 3 months ago

Unless you are the one having to maintain that library. Then it just migrates the complexity to another location.

tmoertel3• 3 months ago

Unless you are the one having to maintain that library. Then it just migrates the complexity to another location.

No, it’s a win, even then.

Say you are writing an operating system, and one of the fundamental data structures you use all over the place is a concurrency-safe linked list.

Option 1 is to manipulate the relevant instances of the linked list directly—whenever you need to insert, append, iterate over, or delete from any list from any subsystem in your operating system. So you’ll have low-level list-related lock and pointer operations spread throughout the entire code base. Each one of these operations requires you to struggle with the list at the abstraction level and at the implementation level.

Option 2 is to factor out the linked-list operations and isolate them in a small library. Yes, you must still struggle with the list at the abstraction and implementation levels in this one small library, but everywhere else the complexity has been reduced to having to struggle with the abstraction level only, and the abstraction is a small set of straightforward operations that is easy to wrap your head around.

The sole difference between the options, as you wrote, is that “the complexity just migrates to another location.” But which would you rather maintain?

That was Ousterout’s point.

ozgrakkurt2• 3 months ago

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

ghm21802• 3 months ago

Any recommendations? I read designing data intensive applications(DDIA) which was really good. But it is by Martin Klepmann who as I understand is an academic. Reading PEPs is also nice as it allows one to understand the motivations and "Why should I care" about feature X.

ozgrakkurt2• 3 months ago

https://www.amazon.com/Computer-Architecture-Quantitative-Ap...

https://casual-effects.blogspot.com/2014/05/a-computer-scien...

azath92• 3 months ago

the python cookbook is good. and fluent python is more from principles rather than application (obvs both python specific). I also like philosophy of software design. tiny little book that uses simple example (class that makes a text editor) to talk about complexity, not actually about making a text editor at all.

WillAdams2• 3 months ago

Ousterhout's _A Philosophy of Software Design_ (mentioned elsethread) would be mine.

devgoncalo• 3 months ago

The Pragmatic Programmer https://www.amazon.com/Pragmatic-Programmer-Journeyman-Maste...

pratikdeoghare• 3 months ago

https://norvig.github.io/paip-lisp/#/

Really great book even if don’t care about lisp or ai.

jfl0• 3 months ago

fwiw, Kleppmann sold his start up to LinkedIn and worked there on Kafka before writing DDIA!

Marianne Bellotti's Kill It with Fire is a quick but good read

newsoftheday3• 3 months ago

I also recommend avoiding anyone who rails against SOLID or OOP.

_dain_• 3 months ago

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

dgb232• 3 months ago

In many cases, simpler code is faster, and fast code makes for simpler systems. (...)

I wholeheartedly agree with you here. You mentioned a few architectural/backend issues that emerge from bad performance and introduce unnecessary complexity.

But this also happens in UI: Optimistic updates, client side caching, bundling/transpiling, codesplitting etc.

This is what happens when people always answer performance problems with adding stuff than removing stuff.

hliyan• 3 months ago

I absolutely cannot stand people who recite this quote but has no knowledge of the sentences that come before or after it: "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%."

randusername• 3 months ago

Don't forget:

- The customer is always right in matters of taste

- Jack of all trades, master of none, but oftentimes better than a master of one

- Curiosity killed the cat, but satisfaction brought it back

- A few bad apples spoil the barrel

- Great minds think alike, though fools seldom differ

Even "pull yourself up by your bootstraps" was originally meant to highlight the absurd futility of a situation.

cogman104• 3 months ago

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.

Just a little historic context will tell you what Knuth was talking about.

Compilers in the era of Knuth were extremely dumb. You didn't get things like automatic method inlining or loop unrolling, you had to do that stuff by hand. And yes, it would give you faster code, but it also made that code uglier.

The modern equivalent would be seeing code working with floating points and jumping to SIMD intrinsics or inline assembly because the compiler did a bad job (or you presume it did) with the floating point math.

That is such a rare case that I find the premature optimization quote to always be wrong when deployed. It's always seems to be an excuse to deploy linear searches and to avoid using (or learning?) language datastructures which solve problems very cleanly in less code and much less time (and sometimes with less memory).

mojuba2• 3 months ago

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.

AussieWog932• 3 months ago

I recently had success with a problem I was having by basically doing the following:

- Write a correct, pretty implementation

- Beat Claude Code with a stick for 20 minutes until it generated a fragile, unmaintainable mess that still happened to produce the same result but in 300ms rather than 2500ms. (In this step, explicitly prompting it to test rather than just philosophising gets you really far)

- Pull across the concepts and timesaves from Claude's mess into the pretty code.

Seriously, these new models are actually really good at reasoning about performance and knowing alternative solutions or libraries that you might have only just discovered yourself.

mojuba2• 3 months ago

However, a correct, pretty and fast solution may exist that neither of you have found yet.

But yes, the scope and breadth of their knowledge goes far beyond what a human brain can handle. How many relevant facts can you hold in your mind when solving a problem? 5? 12? An LLM can take thousands of relevant facts into account at the same time, and that's their superhuman ability.

theandrewbailey• 3 months ago

Modern SaaS: make it "pretty", then make it work, then make it "pretty" again in the next release. Make fast? Never.

IshKebab• 3 months ago

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

conartist6• 3 months ago

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

ghm21802• 3 months ago

This is doubly true in Machine Learning Engineering. Knowing what methods to avoid is just as important to know what might work well and why. Importantly a bunch of Data Science techniques — and I use data science in the sense of making critical team/org decisions — is also as important for which you should understand a bit of statistics not only data driven ML.

Silamoth3• 3 months ago

Statistics is absolutely fundamental to data science. But I’m not sure this relates to the above idea of “laws” being internally contradictory?

AussieWog932• 3 months ago

DRY is my pet example of this.

I've seen CompSci guys especially (I'm EEE background, we have our own problems but this ain't one of them) launch conceptual complexity into the stratosphere just so that they could avoid writing two separate functions that do similar things.

pydry3• 3 months ago

DRY is misunderstood. It's definitely a fundamental aspect of code quality it's just one of about 4 and maximizing it to the exclusion of the others is where things go wrong. Usually it comes at the expense of loose coupling (which is equally fundamental).

The goal ought to be to aim for a local minima of all of these qualities.

Some people just want to toss DRY away entirely though or be uselessly vague about when to apply it ("use it when it makes sense") and thats not really much better than being a DRY fundamentalist.

busfahrer• 3 months ago

I think I remember a Carmack tweet where he mentioned in most cases he only considers it once he reaches three duplicates

iwontberude• 3 months ago

Why do the have to be so smart but so annoying at the same time?

zahlman2• 3 months ago

I've heard that story a few times (ironically enough) but can't say I've seen a good example. When was over-architecture motivated by an attempt to reduce duplication? Why was it effective in that goal, let alone necessary?

aworks2• 3 months ago

I worked for a company that also had hardware engineers writing RTL. Our software architect spent years helping that team reuse/automate/modularize their code. At a mininum, it's still just text files with syntax, despite rather different semantics.

ericmcer3• 3 months ago

DRY and KISS were right next to each other which I thought was funny.

blandflakes• 3 months ago

This was also true of Amazon's Leadership Principles. They are pretty reasonable guidelines, but in a debate, it really came down to which one you could most reasonably weaponize in favor of your argument, even to the detriment of several others.

Which maybe is also fine, I dunno :)

rustyhancock• 3 months ago

It's because they are heurists intended to be applied by knowledgeable and experienced humans.

It can be quite hard to explain when a student asks why you did something a particular way. The truthful answer is that it felt like the right way to go about it.

With some thought you can explain it partly - really justify the decision subconsciously made.

If they're asking about a conscious decision that's rarely much more helpful that you having to say that's what the regulations, or guidelines say.

Where they really learn is seeing those edge cases and gray areas

rapnie4• 3 months ago

I like alternatives to formal IT lawfare, like CUPID [0] properties for Joyful coding by Dan North, as alternative to SOLID principles.

[0] https://cupid.dev/

diehunde• 3 months ago

I guess that's why confirmation bias is also listed?

ChrisMarshallNY2• 3 months ago

Great point.

Sort of like a real code of law.

jolt42• 3 months ago

I'll propose this as the only unbreakable law: "everything in moderation", which I feel implies any law is breakable, which now this is sounding like the barber's paradox. What else does anyone propose as unbreakable?

zdc1• 3 months ago

Counterpoint: "everything in moderation, including moderation"

alok-g• 3 months ago

> everything in moderation

Saying this is like saying 'pick the optimum point' without saying anything about how to find the optimum point. This cannot be a law, it is the definition of optimum.

Note that optimum point need not be somewhere in the middle or 'inside', like a maxima. The optimum point could very well be on an extreme of the domain (input variables space).

davedx2• 3 months ago

As a very senior SWE with a decent amount of eng decision making responsibility these days I still find I get so much mileage out of KISS and YAGNI that I never really think about any other laws.

So much SWE is overengineering. Just like this website to be honest. You don't get away with all that bullshit in other eng professions where your BoM and labour costs are material.

ryandrake• 3 months ago

I always thought it would be great if every line of software (or, chose some other unit of complexity) added to the unit cost of creating each copy. Like every bolt or gasket adds a few cents the the BOM of a piece of hardware. That fictional world would have simple, fast, and higher quality software programs.

ericmcer3• 3 months ago

Most of them felt contradictory and kind of antiquated.

Reading through the list mostly made me feel sad. You can't help but interpret these through the modern lens of AI assisted coding. Then you wonder if learning and following (some) of these for the last 20 years is going to make you a janitor for a bunch of AI slop, or force you into a coding style where these rules are meaningless, or make you entirely irrelevant.

mday27• 3 months ago

Seems to me like there's also a divide between observational laws (e.g. Hyrum's Law just says "this seems to be true") and prescriptive laws (e.g. Knuth's Law, which is really a statement about how you ought to behave)

httpz• 3 months ago

That's why we call it software engineering, not software science.

heresie-dabord• 3 months ago

these "laws" contain so many internal contradictions

Also notice how many of the so-called _software laws_ are actually statements about human behaviour and people-problems.

Confirmation bias, Dunning-Kruger Effect, Sunk-Cost Fallacy, Ringlemann Effect, Price's Law, Putt's Law, Conway's Law, Brook's Law, Peter Principle, Hanlon's Razor, Amara's Law...

Of the 59 "laws", only a small number are guiding principles specifically about planning and software.

Human behaviour is hard to change -- the same dysfunction can be seen everywhere. As a fundamental principle, you need to use the right/best tool for the job; you will know when you are using the wrong tool/solution because you'll spend a significant amount of time trying to correct/mask the unwanted consequences.

And if you enter a shop where many tools are wrong... consider going to work in a different shop.

xnx2• 3 months ago

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.

More like the Bible of Software Engineering then

d--b• 3 months ago

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.

https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule

tgv• 3 months ago

Shouldn't it also be able to read email? I think that was a law too.

Anyway, the list seems like something AI scraped and has a strong bias towards "gotcha" comments from the likes of reddit.

tfrancisl• 3 months ago

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.

r0ze-at-hn• 3 months ago

Love the details sub pages. Over 20 years I collected a little list of specific laws or really observations (https://metamagic.substack.com/p/software-laws) 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.

Antibabelic3• 3 months ago

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"?

horsawlarway5• 3 months ago

At least for your last point... ideally never.

Look, I understand the intent you have, and I also understand the frustration at the lack of care with which many companies have acted with regards to personal data. I get it, I'm also frustrated.

But (it's a big but)...

Your suggestion is that we hold people legally responsible and culpable for losing a confrontation against another motivated, capable, and malicious party.

That's... a seriously, seriously, different standard than holding someone responsible for something like not following best practices, or good policy.

It's the equivalent of killing your general when he loses a battle.

And the problem is that sometimes even good generals lose battles, not because they weren't making an honest effort to win, or being careless, but because they were simply outmatched.

So to be really, really blunt - your proposal basically says that any software company should be legally responsible for not being able to match the resources of a nation-state that might want to compromise their data. That's not good policy, period.

Antibabelic3• 3 months ago

Incidents happen in the meat world too. Engineers follow established standards to prevent them to the best of their ability. If they don't, they are prosecuted. Nobody has ever suggested putting people in jail for Russia using magic to get access to your emails. However, in the real world, there is no magic. The other party "outmatches" you by exploiting typical flaws in software and hardware, or, far more often, in company employees. Software engineering needs to grow up, have real certification and standards bodies and start being rigorously regulated, unless you want to rely on blind hope that your "general" has been putting an "honest effort" and showing basic competence.

jcgrillo7• 3 months ago

any software company should be legally responsible for not being able to match the resources of a nation-state that might want to compromise their data

No. Not the company, holding companies responsible doesn't do much. The engineer who signed off on the system needs to be held personally liable for its safety. If you're a licensed civil engineer and you sign off on a bridge that collapses, you're liable. That's how the real world works, it should be the same for software.

fineIllregister• 3 months ago

We have HIPAA in the US for health care data. There have been no disastrous consequences to holding people and organizations responsible for breaches.

datadrivenangel3• 3 months ago

It's important to occasionally execute or imprison a general to motivate the remaining generals. Rarely though.

vpol• 3 months ago

Is it not the same as https://github.com/dwmkerr/hacker-laws ?

threepts• 3 months ago

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

RivieraKid2• 3 months ago

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.

kijin• 3 months ago

What's the smallest unit of functionality to which your principle applies?

For example, each comment on HN has a line on top that contains buttons like "parent", "prev", "next", "flag", "favorite", etc. depending on context. Suppose I might one day want to remove the "flag" functionality. Should each button be its own file? What about the "comment header" template file that references each of those button files?

sverhagen• 3 months ago

Maybe the buttons shouldn't be their own files, but the backend functionality certainly could be. I don't do this, but I like the idea.

jpitz• 3 months ago

I think that if you continue along the logical progression of the parent poster, then maybe the smaller units of functionality would be represented by simple ranges of lines of text. Given that, deleting a single button would ideally mean a single contiguous deletion from a file, versus deleting many disparate lines.

balamatom• 3 months ago

The `comment_header` template would iterate over the files in `comment_header.d/*`, which would, admittedly, need forced sorted naming:

100_parent.template

150_context.template

200_prev_next.template

300_flag.template

350_favorite.template

Looks odd with the numbering, no?

But then you get the added benefit of being able to refer to them by numbers, just "100" or "300" without having to glue humanlang inflection, declension, punctuation onto identifiers that happen to be words...

Some places where you can see this pattern: BASIC's explicit line numbering; non-systemd init systems.

danparsonson• 3 months ago

Features arise out of the composition of fundamental units of the system, they're not normally first class units themselves. Can you give an example?

RivieraKid2• 3 months ago

For example using nested .gitignore files vs using one root .gitignore file. I guess this principle is related to this one:

Imagine the code as a graph with nodes and edges. The nodes should be grouped in a way that when you display the graph with grouped nodes, you see few edges between groups. Removing a group means that you need to cut maybe 3 edges, not 30. I.e. you don't want something where every component has a line to every other component.

Also when working on a feature - modifying / adding / removing, ideally you want to only look at an isolated group, with minimal links to the rest of the code.

layer83• 3 months ago

Functionalities aren’t necessarily orthogonal to each other; features tend to interact with one another. “Avoid coupling between unrelated functionalities” would be more realistic.

skydhash3• 3 months ago

Now, I tend towards the C idiom of having few files and not a deep structure and away from the one class, one file of Java. Less files to rename when refactoring and less files to open trying to understand an implementation.

dhosek2• 3 months ago

One advantage of more smaller files is that merge conflicts become less common. I would guess that at least half of the trivial merge conflicts I see are two unrelated commits which both add some header or other definition at the top of the file, but because both are inserted at line 17, git looks at it and says, “I give up.”

This in itself might not be enough to justify this, but the fewer files will lead to more challenges in a collaborative environment (I’d also note that more small files will speed up incremental compilations since unchanged code is less likely to get recompiled which is one reason why when I do JVM dev, I never really think about compilation time—my IDE can recompile everything quickly in the background without my noticing).

voiceofunreason2• 3 months ago

MarkLowenstein• 3 months ago

YES! "Deletability"

serious_angel3• 3 months ago

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

bronlund• 3 months ago

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

Symmetry2• 3 months ago

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

someguyiguess4• 3 months ago

That is exactly what I would expect from someone with your username. Bravo.

fenomas• 3 months ago

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:

Fen's law: 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.

ndr• 3 months ago

Same vibe, different angle:

11. Abstractions don’t remove complexity. They move it to the day you’re on call.

Source: https://addyosmani.com/blog/21-lessons/

Symmetry2• 3 months ago

"Any problem in computer science can be solved with another level of indirection...except for the problem of too many levels of indirection."

dassh• 3 months ago

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.

someguyiguess4• 3 months ago

Especially since a lot of them are written in a tongue-in-cheek way. And many are contradictory.

Sergey777• 3 months ago

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.

James_K• 3 months ago

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.

wesselbindt• 3 months ago

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.

urxvtcd• 3 months ago

Well, ackchyually, you can not pick P, it's just not cheap. You could imagine a network behaving like a motherboard really.

traderj0e5• 3 months ago

In practice a quorum mechanism gets you close enough to picking all three in CAP, doesn't it? But it's still useful to teach.

Aaargh20318• 3 months ago

I’m missing Curly’s Law: https://blog.codinghorror.com/curlys-law-do-one-thing/

“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.”

ipnon• 3 months ago

I usually invoke this by naming with POSIWID.

inetknght4• 3 months ago

It must not be both a floor polish and a dessert topping.

I worked as a janitor for four years near a restaurant, so I know a little bit about floor polishing and dessert toppings. This law might be a little less universal than you think. There are plenty of people who would happily try out floor polish as a dessert topping if they're told it'll get them high.

rapnie4• 3 months ago

Borax is an example of a substance that is simultaneously used for skin care, household cleaning, as soldiering flux, and ant killer. But I guess it is a constant with variable effects. Hard to be found in local shops anymore.

aworks2• 3 months ago

I worked for awhile as a janitor in a college dorm. Not an easy job but it definitely revealed a side of humanity I might not have otherwise seen. Especially the clean out after students left for the year.

otterley2• 3 months ago

It’s a reference to a very old SNL sketch called “shimmer”. https://www.youtube.com/shorts/03lLPUYkpYM

It probably won’t be up very long but it’s a classic.

js8• 3 months ago

I thought that you were about to write: "as a janitor in a restaurant, the dessert topping is sometimes used as a floor polish".

CyberDildonics2• 3 months ago

floor polish as a dessert topping if they're told it'll get them high.

I think that would be called a drug, not a desert topping.

normie3000• 3 months ago

White vinegar is a fierce cleaning product and a salad dressing. Although to me it has the disadvantage of tasting like a cleaning product.

shermantanktop2• 3 months ago

Oh! I didn’t have a name for this one, but it’s a lesson I’ve learned. E.g. if variable x is non-zero, then variable y will be set to zero. Don’t check variable y to find out whether x is zero. And definitely don’t repurpose y for some other function in cases where it’s otherwise unused.

pc862• 3 months ago

For modern day web developers there are very, very, very few things that fall into the "if you do this you should probably be escorted out of the building on the first offense" category, but "reusing a variable because it's 'not being used'" might be on that list. I can maybe see the argument in very low memory embedded systems or similar systems where I'm not even qualified to come up with examples but not in anything that regularly shows up on HN for example.

estimator72922• 3 months ago

Shellac is both a floor polish and a food additive, particularly in candy.

Used to be, anyway. Modern alternatives are much better. It's still used as glue in wind instruments though.

sdeiley• 3 months ago

Eh. I love absl::StatusOr<T> at Google

m4633• 3 months ago

As a computer person, I hated math/physics/science because of the one-letter (greek) variable names.

Of course some of that osmosizes back via lisp and APL.

tsoukase• 3 months ago

That was the exact reason I liked math. Maybe because I am Greek.

duc_minh• 3 months ago

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.

rtrigoso• 3 months ago

not just you, I am getting the same error

netdevphoenix• 3 months ago

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

milanm0815• 3 months ago

Fixed

bpavuk• 3 months ago

This site was paused as it reached its usage limits. Please contact the site owner for more information.

ha, someone needs to email Netlify...

bakkerinho• 3 months ago

This site was paused as it reached its usage limits. Please contact the site owner for more information.

Law 0: Fix infra.

andrerpena• 3 months ago

This looks like a static website that could be served for free from Cloudflare Pages or Vercel, with a nearly unlimited quota. And still... It's been hugged to death, which is ironic, considering it's a software engineering website :).

mghackerlady• 3 months ago

Hell, something like this probably doesn't even need that. Throw it on a debian box running nginx or apache and you'll probably be set (though, with how hard bots have been scraping recently it might be harder than that)

asdfasgasdgasdg• 3 months ago

Law 1: caching is 90-99% of performance.

arnorhs2• 3 months ago

are you saying performance is 90-99% caching? If so that is so obviously untrue.

If you are saying you _can_ fix 90-99% of performance bottlenecks eventually with caching, that may be true, but doesn't sound as nice

the_arun• 3 months ago

Laws are there to be broken.

esafak• 3 months ago

"Performance doesn't matter!"

hermaine• 3 months ago

Waybackmachine to the rescue :D https://web.archive.org/web/20260421113202/https://lawsofsof...

kurnik• 3 months ago

So somebody who doesn’t know how to properly host a static website wants to teach me about software engineering. Cool. 99% sure it’s a vibecoded container for AI slop anyway.

milanm0815• 3 months ago

Fixed, thanks!

jvanderbot• 3 months ago

Prior probability of a prompt-created website: 50%.

Posterior probability of a prompt-created website: 99%.

dgb232• 3 months ago

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: https://lawsofsoftwareengineering.com/laws/testing-pyramid/

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.

nazgul17• 3 months ago

I think the general wisdom in that scenario is to keep them around until they get in the way. Let them provide a bit of value until they start being a cost.

arnorhs2• 3 months ago

Since the site is down, you can use the archive.org link:

https://web.archive.org/web/20260421113202/https://lawsofsof...

milanm0815• 3 months ago

Fixed

andreygrehov• 3 months ago

`Copy as markdown` please.

Waterluvian• 3 months ago

I think it would be cool to have these shown at random as my phone’s “screensaver”

noduerme• 3 months ago

I'd like to propose a corollary to Gall's Law. Actually it's a self-proving tautology already contained with the term "lifecycle." Any system that lasts longer than a single lifecycle oscillates between (reducing to) simplicity and (adding) complexity.

My bet is on the long arc of the universe trending toward complexity... but in spite of all this, I don't think all this complexity arises from a simple set of rules, and I don't think Gall's law holds true. The further we look at the rule-set for the universe, the less it appears to be reducible to three or four predictable mechanics.

jt2190• 3 months ago

I think this site doesn’t capture Gall’s Law correctly, and your observations are closer to the original.

Gall notes that the universe naturally trends toward complexity and unintended consequences and therefore complex designs should be assumed to already be full of these unintended consequence “bugs”. He proposes that systems should be designed:

- with less scope to reduce unintended consequences,

- with less rigidity to allow for workarounds when unintended consequences arise, and

- to take advantage of “momentum” to reduce the required energy to use the system correctly. In other words make the right thing the easy thing, remembering that the easiest thing to do is nothing, thus systems will halt if operators get too busy with other tasks.)

JensRantil• 3 months ago

There is also https://hacker-laws.com.

herodotus• 3 months ago

Knuth's Optimization Principle: The computer scientist Rod Burstall had a pithy way of saying this: "Efficiency is the enemy of clarity"

ebonnafoux2• 3 months ago

There is a small typos in The Ninety-Ninety Rule

The first 90% of the code accounts for the first 90% of development time; the remaining 10% accounts for the other 90%.

It should be 90% code - 10% time / 10% code - 90% time

Edman274• 3 months ago

It sounds like you are unfamiliar with the idea that software engineering efforts can be underestimated at the outset. The humorous observation here is that the total is 180 percent, which mean that it took longer than expected, which is very common.

ebonnafoux2• 3 months ago

Oh OK, that is something I learn today.

cogman104• 3 months ago

Uhh, I knew I wasn't going to like this one when I read it.

Premature Optimization (Knuth's Optimization Principle)
Another example is prematurely choosing a complex data structure for theoretical efficiency (say, a custom tree for log(N) lookups) when the simpler approach (like a linear search) would have been acceptable for the data sizes involved.

This example is the exact example I'd choose where people wrongly and almost obstinately apply the "premature optimization" principles.

I'm not saying that you should write a custom hash table whenever you need to search. However, I am saying that there's a 99% chance your language has an inbuilt and standard datastructure in it's standard library for doing hash table lookups.

The code to use that datastructure vs using an array is nearly identical and not the least bit hard to read or understand.

And the reason you should just do the optimization is because when I've had to fix performance problems, it's almost always been because people put in nested linear searches turning what could have been O(n) into O(n^3).

But further, when Knuth was talking about actual premature optimization, he was not talking about algorithmic complexity. In fact, that would have been exactly the sort of thing he wrapped into "good design".

When knuth wrote about not doing premature optimizations, he was living in an era where compilers were incredibly dumb. A premature optimization would be, for example, hand unrolling a loop to avoid a branch instruction. Or hand inlining functions to avoid method call overhead. That does make code more nasty and harder to deal with. That is to say, the specific optimizations knuth was talking about are the optimizations compilers today do by default.

I really hate that people have taken this to mean "Never consider algorithmic complexity". It's a big reason so much software is so slow and kludgy.

bigfishrunning• 3 months ago

Yeah, for every Knuth there are 10000 copies of schlemiel the painter

krust• 3 months ago

Another example is prematurely choosing a complex data structure for theoretical efficiency (say, a custom tree for log(N) lookups) when the simpler approach (like a linear search) would have been acceptable for the data sizes involved.

To be fair, a linear search through an array is, most of the time, faster than a hash table for sufficiently small data sizes.

cogman104• 3 months ago

I'd say that this is premature optimization.

It doesn't take long for hash or tree lookups to start outperforming linear search and, for small datasets, it's not frequently the case that the search itself is a performance bottleneck.

macintux• 3 months ago

Some similarly-titled (but less tidily-presented) posts that have appeared on HN in the past, none of which generated any discussion:

* https://martynassubonis.substack.com/p/5-empirical-laws-of-s...

* https://newsletter.manager.dev/p/the-unwritten-laws-of-softw..., which linked to:

* https://newsletter.manager.dev/p/the-13-software-engineering...

austin-cheney3• 3 months ago

My own personal law is:

When it comes to frameworks (any framework) any jargon not explicitly pointing to numbers always eventually reduces down to some highly personalized interpretation of easy.

It is more impactful than it sounds because it implicitly points to the distinction of ultimate goal: the selfish developer or the product they are developing. It is also important to point out that before software frameworks were a thing the term framework just identifies a defined set of overlapping abstract business principles to achieve a desired state. Software frameworks, on the other hand, provide a library to determine a design convention rather than the desired operating state.

nashashmi• 3 months ago

Yii frameworks were full of that jargon.

I had a hard time learning the whole mvc concept

superxpro12• 3 months ago

The wadsworth constant is missing :| https://www.reddit.com/r/reddit.com/comments/kxtzp/and_so_th...

compiler-guy• 3 months ago

As true and amusing as the wadsworth constant is, it has very little to do with software engineering.

Kinrany2• 3 months ago

SOLID being included immediately makes me have zero expectation of the list being curated by someone with good taste.

detectivestory• 3 months ago

I'm seeing some hate for SOLID in these comments and I am a little surprised. While I don't think it should ever be used religiously, I would much rather work on a team that understood the principles than one that didn't.

causal2• 3 months ago

I think it's probably pointing toward the general harm that thinking only in objects has done to programming as a practice

AtNightWeCode3• 3 months ago

I think the baseline is that code can be trash and still comply with SOLID. Therefor people get frustrated over it. Getting PR:s rejected and so on.

I think it is better to have real requirements like: The code needs to be testable in a simple way.

heap_perms• 3 months ago

That's interesting, what makes you think that? Not long ago, I was working on my degree in Computer Science (Software Engineering), and we were heavily drilled on this principle. Even then, I found it amusing how all the professors were huge fanboys of SOLID. It was very dogmatic.

zelphirkalt3• 3 months ago

Professors ... They are likely knowledgeable about the abstract things in computer science, but when it comes to actually writing code and guidance on that, I would only trust the ones, that have a background of getting deep into the code and actually making things. For example when I was studying I experienced a variety of professors:

One who was a Python core developer and who knew many languages and could "compile in his head" what the result of some code will be in assembly. I would trust this one.

One, who criticized my C code for having multiple procedures, because that would make it look after more pointers and told me it would be better all in one long procedure, lol, without ever even considering the readability. That one was likely also simply wrong because of the compiler probably inlining things anyway. That one taught a math lecture and used C. Needless to say I wouldn't trust that one when it comes to writing good code.

Then I had a math physics guy, who wrote Java 5 or earlier code when it was Java 8 times. That one didn't use generics at all, and cast to Object instead and whatever else. He also explained, that he uses bit shift in a for loop variable update, because that was faster than *2. Yeah, also wouldn't trust that one to give any advice on how to write good code. It taught me to be very skeptical of mathematicians writing code, unless they have a proven track record of software development skills. This kind of person is the reason why mathematicians and physicists should be supported by an actual software developer, to write their code, and not be too ignorant or arrogant to consider hiring one.

I also had one professor, who taught a math lecture in such a bad way, that it was hard to follow and even his writing on the blackboard was illegible. That one also had another lecture which was mostly talk about Internet and web concepts in one of the most grating accents imaginable, almost comical. I wouldn't trust that one to give advice on writing good code.

Kinrany2• 3 months ago

In modern terms, it's marketing slop. It is what ChatGPT could have created at the time if it was asked to select a bunch of "best practices" and form a punchy acronym out of them.

There's no system, it's five rules selected at random.

Worse, their usefulness varies from hopelessly vague through trivial to actively confusing.

newsoftheday3• 3 months ago

The few on this page today who object to SOLID seem likely to me to be functional programmers who have never understood software engineering principles in the first place.

sov2• 3 months ago

Weird take--SOLID, to me (I work in embedded but have done basically everything), represents a system of design principles that mean well and are probably fine in a heavily OO environment 80% of the time but resoundingly end up prime examples of the pareto principle.

sjducb• 3 months ago

I like the Single responsibility part of SOLID. It makes the code much easier to reason about. The Liskov Substitution principle is also super important. Subclasses should fully replace the parent class.

The I and O of solid are fine and don’t cause too many problems.

But I agree that Dependency Inversion is a recipe for loads of pointless interfaces that are only ever used once. I strongly prefer the traditional pattern where high level modules depend on lower level modules, it’s much simpler.

I think it would be better as SOIL not SOLID.

Maybe they could have replaced the D with DRY…

GuB-422• 3 months ago

Premature optimization is the root of all evil.

There are few principle of software engineering that I hate more than this one, though SOLID is close.

It is important to understand that it is from a 1974 paper, computing was very different back then, and so was the idea of optimization. Back then, optimizing meant writing assembly code and counting cycles. It is still done today in very specific applications, but today, performance is mostly about architectural choices, and it has to be given consideration right from the start. In 1974, these architectural choices weren't choices, the hardware didn't let you do it differently.

Focusing on the "critical 3%" (which imply profiling) is still good advice, but it will mostly help you fix "performance bugs", like an accidentally quadratic algorithms, stuff that is done in loop but doesn't need to be, etc... But once you have dealt with this problem, that's when you notice that you spend 90% of the time in abstractions and it is too late to change it now, so you add caching, parallelism, etc... making your code more complicated and still slower than if you thought about performance at the start.

Today, late optimization is just as bad as premature optimization, if not more so.

tananaev• 3 months ago

With modern tools it should be pretty easy to build scalable solutions. I take premature optimization as going out of your way to optimize something that's already reasonable. Not that you should write really bad code as a starting point.

Sammi3• 3 months ago

The problem is that that this term gets misused to say the opposite of what it was intended for.

It's particularly the kind of people who like to say "hur hur don't prematurely optimize" that don't bother writing decent software to begin with and use the term as an excuse to write poor performing code.

Instead of optimizing their code, these people end up making excuses so they can pessimize it instead.

cstoner2• 3 months ago

Yeah, I interpret "premature optimization" as taking a request that takes 500ms and focusing on saving a couple ms by refactoring logic to avoid a SQL JOIN or something.

Your users are not going to notice. Sure, it's faster but it's not focused on the problem.

austin-cheney3• 3 months ago

The most misunderstood statement in all of programming by a wide margin.

I really encourage people to read the Donald Knuth essay that features this sentiment. Pro tip: You can skip to the very end of the article to get to this sentiment without losing context.

Here ya go: https://dl.acm.org/doi/10.1145/356635.356640

Basically, don't spend unnecessary effort increasing performance in an unmeasured way before its necessary, except for those 10% of situations where you know in advance that crucial performance is absolutely necessary. That is the sentiment. I have seen people take this to some bizarre alternate insanity of their own creation as a law to never measure anything, typically because the given developer cannot measure things.

iamflimflam1• 3 months ago

I have seen people take this to some bizarre alternate insanity of their own creation as a law to never measure anything, typically because the given developer cannot measure things.

Similar to the "code should be self documenting - ergo: We don't write any comments, ever"

Sammi3• 3 months ago

In particular I've seen way too many people use this term as an excuse to write obviously poor performing code. That's not what Knuth said. He never said it's ok to write obviously bad code.

I'm still salty about that time a colleague suggested adding a 500 kb general purpose js library to a webapp that was already taking 12 seconds on initial load, in order to fix a tiny corner case, when we could have written our own micro utility in 20 lines. I had to spend so much time advocating to management for my choice to spend time writing that utility myself, because of that kind of garbage opinion that is way too acceptable in our industry today. The insufferable bastard kept saying I had to do measurements in order to make sure I wasn't prematurely optimizing. Guy adding 500 kb of js when you need 1 kb of it is obviously a horrible idea, especially when you're already way over the performance budget. Asshat. I'm still salty he got so much airtime for that shitty opinion of his and that I had to spend so much energy defending myself.

rkaregaran• 3 months ago

(this is the correct answer, parent needs to understand this better)

sandeepkd• 3 months ago

This is crucial detail that almost everyone misses when they are skimming the topic on surface. The implication is that this statement/law is referenced more often to shut down the architecture designs/discussions

dimitrios12• 3 months ago

Even moreso . I like the Rob Pike restatement of this principle, it really makes it crystal clear:

"You can't tell where a program is going to spend its time. Bottlenecks occur in surprising places, so don't try to second guess and put in a speed hack until you've proven that's where the bottleneck is."

Moreso, in my personal experience, I've seen a few speed hacks cause incorrect behavior on more than one occasion.

giancarlostoro• 3 months ago

except for those 10% of situations where you know in advance that crucial performance is absolutely necessary

Yeah like, NOT indexing any fields in a database, that'll become a problem very quickly. ;)

tshaddox• 3 months ago

Basically, don't spend unnecessary effort increasing performance in an unmeasured way before its necessary, except for those 10% of situations where you know in advance that crucial performance is absolutely necessary. That is the sentiment.

Which is pretty close to just saying "don't do anything unless you have a good reason for doing it."

hinkley2• 3 months ago

Because it reads like permission not to think and for a group of supposed intellectuals we spend a lot of fucking time trying not to think.

Even 'grug brained' isn't about not thinking, it's about keeping capacity in reserve for when the shit hits the fan. Proper Grug Brain is fully compatible with Kernighan's Law.

red_admiral• 3 months ago

Knuth certainly writes better than Dijkstra, even if he lost the "goto" argument in the end.

pelasaco2• 3 months ago

Computer scientist here. I love Donald Knuth, but he never maintained production systems :)

I’m being a bit provocative here, just to make two points:

a) Software development back in the day, especially when it comes to service, reach, security, etc., was completely different from today. Black Friday, millions of users, SLAs, 24-hour service... these didn’t exist back then.

b) Because of so many conditions — some mentioned in point (a) - prematurity ends when the code is live in production. End.

port11• 3 months ago

DRY might be even more misunderstood. We all parrot it to mean don’t duplicate code, forgoing the part where domain and function need to be taken into account.

EGreg• 3 months ago

I would add this: https://magarshak.com/blog/perfection-is-the-enemy-of-the-go...

tehjoker• 3 months ago

I would venture that this statement is not true for library authors. Performance is a large factor in competitive advantage, especially in domains like image analysis or processing large corpuses of text etc.

In these domains, algorithm selection, and fine tuning hot spots pays off significantly. You must hit minimum speeds to make your application viable.

cogman104• 3 months ago

Completely agreed here [1].

And as I point out, what Knuth was talking about in terms of optimization was things like loop unrolling and function inlining. Not picking the right datastructure or algorithm for the problem.

I mean, FFS, his entire book was about exploring and picking the right datastructures and algorithms for problems.

[1] https://news.ycombinator.com/item?id=47849194

enraged_camel• 3 months ago

> Today, late optimization is just as bad as premature optimization, if not more so.

You are right about the origin of and the circumstances surrounding the quote, but I disagree with the conclusion you've drawn.

I've seen engineers waste days, even weeks, reaching for microservices before product-market fit is even found, adding caching layers without measuring and validating bottlenecks, adding sharding pre-emptively, adding materialized views when regular tables suffice, paying for edge-rendering for a dashboard used almost entirely by users in a single state, standing up Kubernetes for an internal application used by just two departments, or building custom in-house rate limiters and job queues when Sidekiq or similar solutions would cover the next two years.

One company I consulted for designed and optimized for an order of magnitude more users than were in the total addressable market for their industry! Of that, they ultimately managed to hit only 3.5%.

All of this was driven by imagined scale rather than real measurements. And every one of those choices carried a long tail: cache invalidation bugs, distributed transactions, deployment orchestration, hydration mismatches, dependency array footguns, and a codebase that became permanently harder to change. Meanwhile the actual bottlenecks were things like N+1 queries or missing indexes that nobody looked at because attention went elsewhere.

cstoner2• 3 months ago

Thank your for posting this. I disagreed with OP but couldn't _quite_ find the words to describe why. But your post covers what i was trying to say.

I was quite literally asked to implement an in-memory cache to avoid a "full table scan" caused by a join to a small DB table recently. Our architect saw "full table scans" in our database stats and assumed that must mean a performance problem. I feel like he thought he was making a data-driven profiling decision, but seemed to misunderstand that a full-table scan is faster for a small table than a lookup. That whole table is in RAM in the DB already.

So now we have a complex Redis PubSub cache invalidation strategy to save maybe a ms or two.

I would believe that we have performance problems in this chunk of code, and it's possible an in-memory cache may "fix" the issue, but if it does, then the root of the problem was more likely an N+1 query (that an in-memory cache bandaids over). But by focusing on this cache, suddenly we have a much more complex chunk of code that needs to be maintained than if we had just tracked down the N+1 query and fixed _that_

Esophagus4• 3 months ago

All of this was driven by imagined scale rather than real measurements

Yes. When I was a young engineer, I was asked to design something for a scale we didn’t even get close to achieving. Eventual consistency this, event driven conflict resolution that… The service never even went live because by the time we designed it, everyone realized it was a waste of time.

I learned it makes no sense to waste time designing for zillions of users that might never come. It’s more important to have an architecture that can evolve as needs change rather than one that can see years into the future (that may never come).

xnx2• 3 months ago

making your code more complicated and still slower than if you thought about performance at the start.

Not if your optimization for performance is some Rube Goldberg assemblage of microservices and an laundry list of AWS services.

causal2• 3 months ago

Exactly. Today "premature optimization" almost always means unnecessary infra or abstractions or some other complexity- not DS&A choices.

pcblues2• 3 months ago

I still don't understand microservices for anything short of a NAG of four level architecture.

ghosty1414• 3 months ago

What's the problem with SOLID? It's very very rare that I see a case where going against SOLID leads to better design.

someguyiguess4• 3 months ago

It only applies to the object oriented programming paradigm

dzjkb• 3 months ago

here's a nice critique of SOLID principles:

https://www.tedinski.com/2019/04/02/solid-critique.html

GuB-422• 3 months ago

SOLID tend to encourage premature abstraction, which is a root of evil that is more relevant today than optimization.

SOLID isn't bad, but like the idea of premature optimization, it can easily lead you into the wrong direction. You know how people make fun of enterprise code all the time, that's what you get when you take SOLID too far.

In practice, it tends to lead to a proliferation of interfaces, which is not only bad for performance but also result in code that is hard to follow. When you see a call through an interface, you don't know what code will be run unless you know how the object is initialized.

sroussey• 3 months ago

In a way, SOLID is premature optimization. You are optimizing abstractions before knowing how the code is used in practice. Lots of code will be written and never changed again, but a minority will see changes quite a bit. Concentrate there. Like you don't need to optimize things that aren't in hot code (usually, omg experience will tell you that all rules have exceptions, including the exceptions).

paulddraper2• 3 months ago

It causes excessive abstraction, and more verbose code.

L and I are both pretty reasonable.

But S and D can easily be taken to excess.

And O seems to suggest OO-style polymorphism instead of ADTs.

jollyllama• 3 months ago

You ARE going to need it.

tonymet• 3 months ago

The wheel is a premature optimization to someone who never figured out how to build one.

throwaway5752• 3 months ago

"Premature optimization is the root of all evil"

Decades in, this is the worst of all of them. Misused by laziness or malice, and nowhere near specific enough.

The graveyard of companies boxed in by past poor decisions is sprawling. And the people that made those early poor decisions bounce around field talking about their "successful track record" of globally poor and locally good architectural decisions that others have had to clean up.

It touches on a real problem, though, but it should be stricken form the record and replaced with a much better principle. "Design to the problem you have today and the problems you have in 6 months if you succeed. Don't design to the problems you'll have have next year if it means you won't succeed in 6 months" doesn't roll off the tongue.

tracker12• 3 months ago

On your last bit, I definitely agree... personally I've leaned more and more into KISS above all else... simple things that are easy to replace are easily replaced only when you need to. Similarly, I also tend to push for initial implementations of many/most things in a scripted language first, mostly for flexibility/simplicity to get a process "right" before worrying about a lot of other things.

One thing that came out of the no-sql/new-sql trends in the past decade and a half is that joins are the enemy of performance at scale. It really helps to know and compromise on db normalization in ways such as leaning on JSON/XML for non-critical column data as opposed to 1:1/children/joins a lot of the time. For that matter, pure performance and vertical scale have shifted a lot of options back from the brink of micro service death by a million paper cuts processes.

jnpnj• 3 months ago

It's a very interesting topic. Even when designing a system, how to modularize, it's healthy to wait until the whole context is in sight. It's a bit of a black art, too early or too late you pay some price.

NikolaosC• 3 months ago

Spent 6 months last year ripping out an abstraction layer that made every request 40ms slower. We profiled, found the hot path, couldn't fix it without a rewrite. The "optimize later" school never tells you later sometimes means never

tombert8• 3 months ago

I'd say it usually means "never".

I also find it a bit annoying is that most people just make shit up about stuff that is "faster". Instead of measuring and/or looking at the compiled bytecode/assembly, people just repeat tribal knowledge about stuff that is "faster" with no justification. I find that this is common amongst senior-level people at BigCos especially.

When I was working in .NET land, someone kept telling me that "switch statements are faster" than their equivalent "if" statements, so I wrote a very straightforward test comparing both, and used dotpeek to show that they compile to the exact same thing. The person still insisted that switch is "faster", I guess because he had a professor tell him this one time (probably with more appropriate context) and took whatever the professor said as gospel.

davedx2• 3 months ago

"today, performance is mostly about architectural choices, and it has to be given consideration right from the start"

This doesn't make sense. Why is performance (via architectural choices) more important today than then?

You can build a snappy app today by using boring technology and following some sensible best practices. You have to work pretty hard to need PREMATURE OPTIMIZATION on a project -- note the premature there

kqr• 3 months ago

In the 1970s computer systems spanned fewer orders of magnitude. Operations generally took somewhere between maybe 1 and 10^8 CPU cycles. Today, the range is closer to 10^-1 to 10^13.

f1shy4• 3 months ago

I agree. But I have to say, when defining the architecture, there are things known that will be terrible bottlenecks later. They should be avoided. Just as the previous comment, about defining proper indices in a database. Optimization means making something that is already “good” and correct better. There is no excuse to make a half ass, bug ridden shitty software, under the excuse “optimization is for later” that is technical debt generation: 2 very different things.

jandrewrogers3• 3 months ago

The big thing that changed is that almost all software performance today is bandwidth-bound at the limit. Not computation-bound. This transition was first noticed in supercomputing around 25 years ago.

Optimization of bandwidth-bound code is almost purely architectural in nature. Most of our software best practices date from a time when everything was computation-bound such that architecture could be ignored with few bad effects.

paulddraper2• 3 months ago

Why is performance (via architectural choices) more important today than then?

There were fewer available layers of abstraction.

Whether you wrote in ASM, C, or Pascal, there was a lot less variance than writing in Rust, JavaScript, Python.

Nevermark• 3 months ago

You can build a snappy app today by using boring technology and following some sensible best practices.

If you are building something with similar practical constraints for the Nth time this is definitely true.

You are inheriting “architecture” from your own memory and/or tools/dependencies that are already well fit to the problem area. The architectural performance/model problem already got a lot of thought.

Lots of problems are like that.

But if you are solving a problem where existing tools do a poor job, you better be thinking about performance with any new architecture.

hunterpayne4• 3 months ago

Sorry but you are just wrong. There are very few coding changes that you can make to fix performance issues that users will notice. Almost all the optimization changes they might notice are architectural changes. This is because CPU bound code is very rare and if you have that case you are probably doing something wrong architecturally. Code being memory bound is 99.999% of the time what is happening. And optimizations to memory bound code are almost always architectural too. Any coding changes, even to a huge platform's codebase can probably be found and fixed in a couple of hours. Anything non-architectural that takes longer than that, is about as likely to create noticeable improvement as you winning the big jackpot in a lottery.

materielle2• 3 months ago

Because you can naively iterate through a million items faster than an additional network round trip would take.

So a lot of code quality debates don’t matter for the typical enterprise app. While a dev spends their afternoon shaving off 100 nanoseconds in the hot path, a second developer on a deadline added a poorly thought out round trip that adds 800milliseconds.

This architectural problems are also more difficult to unwind later since they tend to have cascading effects.

sov2• 3 months ago

"dont prematurely optimize" is talking about optimization SEPERATE from architecture (and how pre-mature optimization as Knuth describes gets in the way of correct architecture). nowadays, almost any optimization purely distinct from architecture is handled either by cpu arch/logic improvements, compiler/interpreter improvements, or buried in the overwhelming tide of cpu speedups, so TODAY these terms get conflated as architecture IS typically how we optimize.

ozim• 3 months ago

Sounds like we agree.

Bunch of stuff is done for us. Using postgres having indexes correct - is not premature optimization, just basic stuff to be covered.

Having double loop is quadratic though. Parallelism is super fun because it actually might make everything slower instead of faster.

snarfy• 3 months ago

I definitely hate SOLID more.

toast0• 3 months ago

I only use mature optimizations, so I'm good.

Thinking about the overall design, how its likely to be used, and what the performane and other requirements are before aggregating the frameworks of the day is mature optimization.

Then you build things in a reasonable way and see if you need to do more for performance. It's fun to do more, but most of the time, building things with a thought about performance gets you where you need to be.

The I don't need to think about performance at all camp, has a real hard time making things better later. For most things, cycle counting upfront isn't useful, but thinking about how data will be accessed and such can easily make a huge difference. Things like bulk load or one at a time load are enormous if you're loading lots of things, but if you'll never load lots of things, either works.

Thinking about concurrency, parallelism, and distributed systems stuff before you build is also pretty mature. It's hard to change some of that after you've started.

Shorel4• 3 months ago

That first sentence.

I want it in a t-shirt. On billboards. Everywhere :)

dec0dedab0de• 3 months ago

I like it as a way to remind myself to not get caught up in the minutiae.

CyberDildonics2• 3 months ago

Unfortunately people do keep repeating it to excuse the fact that they don't know how to optimize in the first place.

Anyone who has done optimization even a little knows that it isn't very difficult, but you do need to plan and architect for it so you don't have to restructure you whole program to get it to run well.

Mostly it's just rationalization, people don't know the skill so they pretend it's not worth doing and their users suffer for it.

If software and website were even reasonably optimized people could just use a computer as powerful as a rasberry pi 5 (except for high res video) for most of what they do day to day.

dorkitude• 3 months ago

Found the overbuilder!

vanguardanon• 3 months ago

Is this less relevant today where if you do go down the wrong architecture it is much cheaper to rewrite everything again in something that is better?

m3kw9• 3 months ago

If you done enough premature optimization, you will know it’s usually wasted, detrimental and bad trade

dartharva• 3 months ago

Strange, this is actually one of the most important things I learnt the hard way as an analyst having had the misfortune of being forced to do local-level data engineering after being tasked with doing extensive BI on heavy data volumes (I don't have engineering education) without cloud ETL. Had someone told me this simple statement before time it would have saved me a LOT of pain and effort.

tombert8• 3 months ago

The biggest issue I have with premature optimization is stuff that really doesn't matter.

For example, in Java I usually use ConcurrentHashMap, even in contexts that a regular HashMap might be ok. My reasoning for this is simple: I might want to use it in a multithreaded context eventually and the performance differences really aren't that much for most things; uncontested locks in Java are nearly free.

I've gotten pull requests rejected because regular HashMaps are "faster", and then the comments on the PR ends up with people bickering about when to use it.

In that case, does it actually matter? Even if HashMap is technically "faster", it's not much faster, and maybe instead we should focus on the thing that's likely to actually make a noticeable difference like the forty extra separate blocking calls to PostgreSQL or web requests?

So that's the premature optimization that I think is evil. I think it's perfectly fine at the algorithm level to optimize early.

xorcist3• 3 months ago

I can fully understand "bickering" about someone sprinkling their favourite data type over a codebase which consistently used a standard data type before. The argument that it might be multithreaded in the futurure does not hold if the rest of the code base clearly was not writen with that in mind. That could even be counter productive, should someone get the misguided idea that it was ready for it.

Make a (very) good argument, and suggest a realtistic path to change the whole codebase, but don't create inconsistency just because it is "better". It is not.

hunterpayne4• 3 months ago

1) You don't need ConcurrentHashMap to make code thread-safe. That's the most extreme version that means that you need a thread-safe iterator too.

2) Locks are cheap

3) I seriously doubt that the difference between a Map and a ConcurrentHashMap is measurable in your app

Which means that both, the comments on your PRs are irrelevant and you are still going too far in your thread-safety. So you are both wrong.

What you are right about is to focus on network calls.

brabel• 3 months ago

I think you are in the wrong. But my reason is that when you support concurrency, every access and modification must be checked more carefully. By using a concurrent Map you are making me review the code as if it must support concurrency which is much harder. So I say don’t signal you want to support concurrency if you don’t need it.

boonzeet• 3 months ago

Ironically to your point, I think adding a ConcurrentHashMap because it might be multithreaded eventually IS premature optimisation.

The work can be done in future to migrate to using ConcurrentHashMap when the feature to add multithreading support is added. There's no sense to add groundwork for unplanned, unimplemented features - that is premature optimisation in a nutshell.

account423• 3 months ago

Compound "not much faster so it doesn't matter" a couple of times and you get todays dog slow software.

kgwxd• 3 months ago

All aphorisms are awful.

theLiminator• 3 months ago

Yeah, I hate that quote too. People take it so out of context and even ignore engineering for reasonable performance out of the box.

I don't blame Knuth, he's talking about focusing on micro-optimizations, but a lot of devs nowadays don't even care to get basic performance right.

SJC_Hacker• 3 months ago

Maybe its just my domain, but most perf problems I've seen relate to architechture and infrastrucutre decisions, and not really code or algorithms. Especially the "microservice" mantra, splitting out simple functions into containers, using k8s, all in the name of "scalability" then being surprised when a simple API call takes several seconds due to all that crud it has to go through.

chrismarlow9• 3 months ago

A better rule is "complicate only if necessary"

rustystump4• 3 months ago

I have worked on projects that had 5 layers of buffer/caching all implementing complicated evictions strategies. This is all a browser client. There were 4 caching layers when i started. I added the 5th caching freq network data to disk which massively improved performance.

This is too true. However, often you dont fully know the shape of the domain until you swing at it and fail.

benrutter• 3 months ago

Today, late optimization is just as bad as premature optimization, if not more so.

I agree but I don't think this discredits the "premature optimisation is the root of all evil" thing, aside from the fact that it's a heavy exaggeration.

The trouble is, people read it as "don't optimise" which is an incredibly bad decision.

Especially in the data world though, I've seen lots of teams really struggle with problems caused by using technologies they don't need (normally spark or kubernetes or both) just because they might need them later.

I think that type of pitfall is what the original quote is warning against.

firemelt• 3 months ago

lol I never seen it that way

its my favorit quotes

premature optimization nowadays looks like choosing microservice when monolith can works just fine

mrzhangbo• 3 months ago

I agree. The main reason for slow development is excessive optimization and over-design.

pelasaco2• 3 months ago

The question is always, "When is it no longer premature?" Normally, it means the system is already in production, users are suffering, and maintaining and supporting it is a nightmare. Then we engineers say, "We have to spend N sprints on that to pay the technical debt."

miki123211• 3 months ago

IMHO "root of all evil" sits there with YAGNI. An useful way to think about the world (overoptimizing early is often as bad as overabstracting, and just as common), but a principle which shouldn't be taken to an extreme.

I think a more useful mental model is of one-way versus two-way decisions (local optimizations can be applied later., the architecture has to be right from the start), as well as expected risks and payoffs.

konovalov-nk• 3 months ago

Recently I stumbled upon this crazy thing: https://github.com/anomalyco/opencode/issues/9676#issuecomme...

`ripgrep` tool call on opencode added `--follow` override, which allowed to traverse symlinks. And you can imagine what happens when symlinks point to ancestors. My 9950x3D CPU had 100% load all the time until I did a bit of research and added config to forbid this on `rg` level.

So I'd refine it as "Premature optimization is the root of all evil. Blatant ignorance of it is even worse."

sigma5• 3 months ago

I would add also Little's law for throughput calculation https://en.wikipedia.org/wiki/Little%27s_law

renticulous• 3 months ago

Linus's Law : "Given enough eyeballs, all bugs are shallow".

Applies to opensource. But it also means that code reviews are a good thing. Seniors can guide juniors to coax them to write better code.

meken• 3 months ago

I love Kernighan’s Law:

"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it"

zelphirkalt3• 3 months ago

Hm, I find this one to be very dubious. When you make an effort to write correct code, you think hard. When you debug, it's more like just looking at the execution of what you have thought of before and thinking "OK where did I go wrong this time? Show me in the process." and it is usually much easier to see why something is wrong or at least at which step it breaks.

lenerdenator• 3 months ago

"No matter how adept and talented you are at your craft with respect to both technical and business matters, people involved in finance will think they know better."

That one's free.

davery22• 3 months ago

A few extra from my own notes-

- Shirky Principle: Institutions will try to preserve the problem to which they are the solution

- Chesterton's Fence: Changes should not be made until the reasoning behind the current state of affairs is understood

- Rule of Three: Refactoring given only two instances of similar code risks selecting a poor abstraction that becomes harder to maintain than the initial duplication

0xbadcafebee• 3 months ago

A law of physics is inviolable.... A law of software engineering is a hot take.

Here's another law: the law of Vibe Engineering. Whatever you feel like, as long as you vibe with it, is software engineering.

rapatel0• 3 months ago

The list is great but the explanation are clearly AI slop.

"Before SpaceX, launching rockets was costly because industry practice used expensive materials and discarded rockets after one use. Elon Musk applied first-principles thinking: What is a rocket made of? Mainly aluminum, titanium, copper, and carbon fiber. Raw material costs were a fraction of finished rocket prices. From that insight, SpaceX decided to build rockets from scratch and make them reusable."

Everything including humans are made of cheap materials but that doesn't convey the value. The AI got close to the answer with it's first sentence (re-usability) but it clearly missed the mark.

ChrisMarshallNY2• 3 months ago

Great stuff!

Where's Chesterton's Fence?

https://en.wiktionary.org/wiki/Chesterton%27s_fence

[EDIT: Ninja'd a couple of times. +1 for Shirky's principle]

smikhanov• 3 months ago

Oh dear, not again: https://lawsofsoftwareengineering.com/laws/brooks-law/

This one belongs to history books, not to the list of contemporary best practices.

lqstuart• 3 months ago

What do you call the law that you violate when you vibe code an entire website for "List of 'laws' of software engineering" instead of just creating a Wikipedia page for it

tjohnell• 3 months ago

Slop’s Law

If it can be slopped, it will be slopped.

Bratmon• 3 months ago

"Creating a Wikipedia page" is a weird suggestion. In 2026, it's actually not possible to create a Wikipedia page unless you're already a deep expert in Wikipedia culture.

(Wikipedia nerds often say "No, anyone can create a page as long as they follow the 137 guidelines!" This is a prank- Wikipedia admins will delete your article no matter how many guidelines it follows)

zelphirkalt3• 3 months ago

Even some 15y ago it was impossible to add web links to communities, even though other web links to similar communities were already in the web links section, because some people weaponized wiki as a moat.

niccl• 3 months ago

Sturgeon's Law (2026): 99% of everything is crap or slop

biscuits12• 3 months ago

Today, I was presented with Claude's decision to include numerous goto statements in a new implementation. I thought deeply about their manual removal; years of software laws went against what I saw. But then, I realized it wouldn't matter anymore.

Then I committed the code and let the second AI review it. It too had no problem with goto's.

Claude's Law: The code that is written by the agent is the most correct way to write it.

voiceofunreason2• 3 months ago

Render therefore unto Caesar the things which are Caesar's; and unto Claude the things that are Claude's.

biscuits12• 3 months ago

And so, it is written:

https://dev.to/solidi/claudes-law-1da7

pkasting2• 3 months ago

This list is missing my personal law, Kasting's Law:

Asking "who wrote this stupid code?" will retroactively travel back in time and cause it to have been you.

omoikane2• 3 months ago

"I'm casting around in my head for someone to blame, and it's just... me, keeps coming back at me."

- Jeremy Clarkson (Top Gear, series 14 episode 5)

pkasting2• 3 months ago

(Tangent: What a pleasure to see your username again; will always think of your readability help fondly!)

cientifico• 3 months ago

There is one missing that i am using as primary for the last 5 years.

The UX pyramid but applied to DX.

It basically states that you should not focus in making something significant enjoyable or convenient if you don't have something that is usable, reliable or remotely functional.

https://www.google.com/search?q=ux+pyramid

Lapsa• 3 months ago

reminder - there's tech out there capable of reading your mind remotely

pcblues2• 3 months ago

In the 25 odd years I developed software, I learnt all the rules the hard way.

Relax. You will make all the mistakes because the laws don't make sense until you trip over them :)

Comment your code? Yep. Helped me ten years later working on the same codebase.

You can't read a book about best practises and then apply them as if wisdom is something you can be told :)

It is like telling kids, "If you do this you will hurt yourself" YMMV but it won't :)

hatsix• 3 months ago

I know it's not software-engineering-only, but Chesterton's Fence is often the first 'law' I teach interns and new hires: https://fs.blog/chestertons-fence/

computerdork5• 3 months ago

This is one of my biggest principles too, "think before you do."

ericmcer3• 3 months ago

They have "Law of Unintended Consequences" on this list which describes the same phenomena.

I always liked the fence story better though.

sltr• 3 months ago

the corollary of Chesterton's Fence is also valuable: don't go putting up unnecessary fences, because others won't be able to take them down

jrmiii• 3 months ago

Found your comment by searching to see if anyone mentioned it. Really key in legacy systems.

deaux• 3 months ago

Laws of Software Engineering (2026 Update)

- Every website will be vibecoded using Claude Opus

This will result in the following:

- The background color will be a shade of cream, to properly represent Anthropic

- There will be excessive use of different fonts and weights on the same page, as if a freshman design student who just learned about typography

- There will be an excess of cards in different styles, a noteworthy amount of which has a colored, round border either on hover or by default on exactly one side of the card

dabedee• 3 months ago

- The domain will be a long title with a dot com at the end.

shimman• 3 months ago

Yeah, the dude vibe coding the site also likely vibe coded the book. Instant pass. Also looking up this person's coding history (mostly cheat sheets and road maps), zero confidence that anything is worthy of note in the book.

ai_fry_ur_brain• 3 months ago

If I think you vibe coded your website im not using your product, reading your blog and will bad mouth you at every opportunity.

komi013• 3 months ago

user name checks out

yesitcan• 3 months ago

None of these things matter anymore. All you need is vibe.

serious_angel3• 3 months ago

Sorry, sometimes, I do wish Hacker News would have a down-vote button...

datadrivenangel3• 3 months ago

Come back after 500 karma.

Divergence422• 3 months ago

Looks a lot different in a 1 person agent based company.

exiguus2• 3 months ago

This website should be a json file

serious_angel3• 3 months ago

Have you checked out?: https://lawsofsoftwareengineering.com/api.json

exiguus2• 3 months ago

Love it :)

hintymad• 3 months ago

With the current AI wave, a fun question to ask is: which of these laws do people think no longer apply.

samuelknight• 3 months ago

I like the website. Simple and snappy.

computerdork5• 3 months ago

Don't see a really important one in my opinion: Refactor legacy code, don't rewrite it. All that cruft you see are bug fixes.

Because rewriting old complex code is way more time consuming that you think it'll be. You have to add not only in the same features, but all the corner cases that your system ran into in the past.

Have seen this myself. A large team spent an entire year of wasted effort on a clean rewrite of an key system (shopping cart at a high-volume website) that never worked... ...although, in the age of AI, wonder if a rewrite would be easier than in the past. Still, guessing even then, it'd be better if the AI refactored it first as a basis for reworking the code, as opposed to the AI doing a clean rewrite of code from the start.

namenotrequired• 3 months ago

The “second system effect” page more or less covers this

computerdork5• 3 months ago

Ah, think there is overlap, but still not the same in my opinion. Having read this just now, the second system effect seems to be more about not getting overly ambitious in the redesign. What the guideline I mentioned is saying is "don't rewrite, refactor.""

As you probably know, there is a tendency when new developers join a team to hate the old legacy code - one of the toughest skills is being able to read someone else's code - so they ask their managers to throw it away and rewrite it. This is rarely worth it and often results in a lot of time being spent recreating fixes for old bugs and corner cases. Much better use of time to try refactoring the existing code first.

Although, can see why you mentioned it from the initial example that I gave (on that rewrite of the shopping cart) which is also covered by the "second system effect." Yeah, thinking back, have seen this too. Overdesign can get really out of hand and becomes really annoying to wade through all that unnecessary complexity whenever you need to make a change.

jaggederest• 3 months ago

TANSTAAFL was always one of my favorites - there ain't no such thing as a free lunch

garff• 3 months ago

Mad AI slop..

regular_trash2• 3 months ago

Hot take - I hate YAGNI. My personal pet peeve is when someone says YAGNI to a structure in the code they perceive as "more complex than they would have done it".

Sure, don't add hooks for things you don't immediately need. But if you are reasonably sure a feature is going to be required at some point, it doesn't hurt to organize and structure your code in a way that makes those hooks easy to add later on.

Worst case scenario, you are wrong and have to refactor significantly to accommodate some other feature you didn't envision. But odds are you have to do that anyway if you abide by YAGNI as dogma.

The amount of times I've heard YAGNI as reasoning to not modularize code is insane. There needs to be a law that well-intentioned developers will constantly misuse and misunderstand the ideas behind these heuristics in surprising ways.

AtNightWeCode3• 3 months ago

It is misused if anything. YAGNI is about functionality. What to add or not. But it has become an excuse for being lazy. Same people that interpreted the line “Working software over comprehensive documentation” as no need for documentation.

traderj0e5• 3 months ago

YAGNI is usually about modularization, often in response to Java-style OOP obsession. Like you don't need to define some big protocol that's only ever going to have one implementation.

traderj0e5• 3 months ago

YAGNI isn't really a law, it's just something you say when you think you ain't gonna need it. You could be wrong, and you actually gonna need it.

TheGRS2• 3 months ago

You know, I mention this stuff all the time in various meetings and discussions. I read a lot of stuff on Hacker News and just have years of accumulated knowledge from the various colleagues I've worked with. Its nice to have a little reference sheet.

blauditore• 3 months ago

Many of the "teams" laws are BS, especially the ones about promotions and management. I've never been a manager or high-level executive, but it's not that all of them are either non-technical or bad managers. It's just that the combination of both skills is rare.

Divergence422• 3 months ago

fascinating and agree with many of the laws. In a 1 person agent only company this hits a bit different.

asmodeuslucifer• 3 months ago

I learned about Dunbar’s number

(~150) is the size of a community in which everyone knows each other’s identities and roles.

In anthropology class. You can ask someone to write down the name of everyone they can think of, real or fictional, live or dead and most people will not make it to 250.

Some individuals like professional gossip columnists or some politicians can remember as many as 1,000 people.

OkayPhysicist• 3 months ago

Dunbar's number is largely psuedoscience. Dunbar just took the group size of gorillas, scaled up to humans based on brain size, and then published, without bothering with silly little details like actually testing human group sizes.

HoldOnAMinute• 3 months ago

I like it, but this could have been a tab delimited text file.

lifeisstillgood• 3 months ago

Just throwing one of my favourites in:

As JFK never said:

“””We do these things, not because they are easy,

But because we thought they would be easy”””

kittikitti• 3 months ago

This is really good and comprehensive, thanks for sharing!

eranation• 3 months ago

Good list. Missing for me

- NIH

- GIGO

- Rule of 3

contingencies• 3 months ago

Better list https://github.com/globalcitizen/taoup

asdfman123• 3 months ago

Leave the code better than you found it

In most places, people don't follow this rule, as it ensures either you're working an extra 10-20 hours a week to keep things clean, or stuck at mid-level for not making enough impact.

I choose the second option. But I see people who utterly trash the codebase get ahead.

darccio• 3 months ago

I wonder if it's usual for other professions/fields to have this tendency to create laws/aphorisms so ingrained. I'm biased as software engineer but it seems to me that is more common in computer science than others.

4dregress• 3 months ago

I like to replace the bus factor with the Lottery Factor.

I actually had a college run over by a bus on the way to work in London, was very lucky and made a full recovery.

Head poking out under the main exit of the bus.

bofia• 3 months ago

It would be nice to see what overlaps

t43562• 3 months ago

The conservation of Complexity (Tesler) seems immediately insightful to me just as a sentence:

  "Every application has an inherent amount of irreducible complexity that can only be shifted, not eliminated."

But then in the explanation seems to me to devolve down to a trite suggestion not to burden your users. This doesn't interest me because users need the level of complexity they need and no more whatever you're doing and making it less causes your application to be an unflexible toy. So this is all, to a degree, obvious.

I think it's more useful to remember when you're refactoring that if you try to make one bit of a system simpler then you often just make another part more complex. Why write something twice to end up with it being just as bad the other way round?

alsetmusic• 3 months ago

Their statement of Dunning-Kruger is overly simplified such as to misdefine it:

The less you know about something, the more confident you tend to be.

From the first line on the wiki article:

systematic tendency of people with low ability in a specific area to give overly positive assessments of this ability.

Or, said another way, the more you know about something the more complexities you're aware of and the better assessment you can make about topics involving such. At least, that's how I understand it in a nutshell without explaining the experiments run and the observations that led to the findings.

toolslive• 3 months ago

maybe add: "the universe is winning" (in the design department). Full quote: "software engineers try to build "idiot-proof" systems, while the universe creates "bigger and better idiots" to break them. So far, the universe is winning"

ryanshrott• 3 months ago

People use the premature optimization principle in exactly the wrong way these days. Knuth's full quote is, "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%." That 97%/3% split is the whole point.

People bring it up to argue for never thinking about performance, which flips the intent on its head. The real takeaway is that you need to spot that critical 3% early enough to build around it, and that means doing some optimization thinking up front, not none at all.

xorcist3• 3 months ago

It's strange to see many non-software related "laws" here, such as the Dilbert Principle, but not Internet cornerstones such as Godwin's Law.

amelius• 3 months ago

No laws related to AI?

nopointttt• 3 months ago

The one I keep coming back to is "code you didn't write is code you can't debug." Every fancy dep I grabbed to save an afternoon ended up costing me weeks later when something upstream broke in some way I had no mental model for. LLM generated code has the same problem now. Looks fine until you hit a case it doesn't cover and you're trying to reverse engineer what you let it write.

AtNightWeCode3• 3 months ago

"Polishing a turd" is missing. Making something slightly better when it should be removed. Like running Flash apps in 2026.

matt765• 3 months ago

I love this

hunterpayne4• 3 months ago

This is the best comment on this article but it was deleted for some reason.

"The meta-law of software engineering: All laws of software engineering will be immediately misinterpreted and mindlessly applied in a way that would horrify their originators. Now that we can observe the behaviour of LLMs that are missing key context, we can understand why."

Or, you can't boil down decades of wisdom and experience into a pithy, 1 sentence quote.

traderj0e5• 3 months ago

Any time someone quotes a law named after some random person, it looks like a stuffy "I know something you don't." Amdahl is probably the only name here that deserves it, and it's a real law. I'd be fine if Eric Brewer put his name on CAP too, also a real law.

YAGNI and "you will ship the org chart" are the two most commonly useful things to remember, but they aren't laws.

galaxyLogic• 3 months ago

The Law of Leaky Abstractions. What is a "leaky" abstraction? How does it "leak"?

I wonder if it should be called "Law of Leaky Metaphors" instead. Metaphor is not the same thing as Abstraction. I can understand a "leaky metaphor" as something that does not quite make it, at least not in all aspects. But what would be a good EXAMPLE of a Leaky Abstraction?

invalidSyntax• 3 months ago

I just wish if this was a requirement to get a job. Everyone needs to know this.

quantum_state• 3 months ago

Unfortunately, violation of any of these laws don't seem to have immediate consequences. That's why the IT industry is in ruin.

merge_software• 3 months ago

YAGNI (You Aren't Gonna Need It)

This one is listed as design, but it could just as easily count as architecture. Guessing a lot developers have worked on scaling with lambda functions or a complex IAC setup when a simple API running on a small VPS would have done the trick, at least until enough people are using the application for it to be considered profitable.

hinkley2• 3 months ago

When we dockerized a service the p95 time in testing notched up a noticeable amount. I was already juggling so much other work at that point that for shits and giggles I tried vertically scaling - reducing the cluster size by half and the cores per server by 2x. Zeroed out the p95 delta.

OPS gave me shit about it, and I was like kiss my ass, the cluster costs EXACTLY the same and deployments are 25% faster.

I think people forget that in the cloud, bigger servers don't really cost more until you get crazy about it.

hpincket• 3 months ago

Time to mention my tongue-in-cheek law:

When describing phenomena in the social world
Software Engineers gravitate towards eponymous 'laws'.

https://pincketslaw.com/

sunkeeh• 3 months ago

Good luck following the Dilbert Principle xD

Just because some things were observed frequently during a certain period, doesn't mean it's a "Law" or even a "Principle"; it's merely a trend.

emmelaich• 3 months ago

Not sure that Linus would actually agree with Linus' law. So it's a bad name. Call it the ESR observation or something else.

Separately, I'd add Rust's API design principles, though it's more of a adjunct with things in common. https://gist.github.com/mjball/9cd028ac793ae8b351df1379f1e72...

0xpgm• 3 months ago

An extension to Zawinski's Law, every web service attempts to expand until it becomes a social network.

bogomog• 3 months ago

A modernization, really.

mchl-mumo• 3 months ago

I find myself guilty of giving over ambitious timelines even when I try to take that into account.

clauderx• 3 months ago

Ah yes my favorite - Conway's Law is just a fancy way of saying "your architecture is whatever your political mess of a org chart accidentally produced, and everyone calls it 'design' afterward to avoid fixing it."

satansdeer2• 3 months ago

It's proverbs, not laws

satansdeer2• 3 months ago

It's proverbs, not laws

Most of them are also wrong

voidifremoved• 3 months ago

Nice site, but missing the Law of Conservation of Misery.

kwar13• 3 months ago

Half of these are not about software engineering and just general management principles.

g051051• 3 months ago

When I first started, I was enamored with technology and programming and computer science. I’m over it.

Wow, that is incredibly sad to hear. I'm 40+ years in, and still love all of that.

sreitshamer• 3 months ago

My favorite is "Software development isn't a code production activity, it's a knowledge acquisition activity."

fomosocial• 3 months ago

Been in Software Engineering for over 2 years now and I'm only hearing most of these named laws for the first time. Am I cooked?

yodsanklai• 3 months ago

Many of these laws are trade-offs to be assessed on a case by case basis. Everybody has a different subjective view and you need to be willing to compromise otherwise you'll be very sad working with other people.

milanm0815• 3 months ago

Thank you all for the valuable feedback! I'll review each comment and improve what I can on the website.

CGMthrowaway• 3 months ago

This website seems heavily inspired by https://lawsofux.com/

brendaninnis• 3 months ago

The Dunning-Kruger Effect card is so bad here. The effect is not that your perceived ability is higher the less skilled you are, but that the gap between your actual ability and perceived ability is larger the less skilled you are (and becomes negative when highly skilled). This is so commonly misstated this way that I think most people have this misunderstanding.

Also they used the graph for the Gartner Hype Cycle as the icon, not the Dunning-Kruger graph.

darthwalsh• 3 months ago

I couldn't find the source on GitHub, but somebody has helpfully scraped them a few hours ago: https://github.com/pascalandy/dotfiles/blob/main/docs/refere...

theRealEros• 3 months ago

Check this out! https://github.com/theElandor/lose_law

timkofu• 3 months ago

How is this different from SWEBOK? https://www.computer.org/education/bodies-of-knowledge/softw...

Laws of Software Engineering

Related Stories