Laws and Principles – tdonker.nl

^{Published: 08.01.2026}

From the site Laws of Software Engineering (2026)

Filter by: Teams, Planning, Quality, Architecture, Scale, Decisions

Teams

Conway’s Law – Your software’s structure ends up looking like your org chart, whether you plan it or not.
Brooks’s Law – Throwing more people at a late project makes it later, not faster.
Dunbar’s Number – People can only maintain about 150 real relationships – teams bigger than that get messy.
Ringelmann Effect – The bigger the group, the less effort each person tends to put in.
Price’s Law – In most teams, a small handful of people do half the actual work.
Putt’s Law – The people who understand the tech aren’t the ones managing it, and vice versa.
Peter Principle – People get promoted until they reach a job they’re not good at, then stay there.
Bus Factor – How many people would need to disappear (get “hit by a bus”) before the project is in serious trouble.
Dilbert Principle – Companies promote their worst performers into management, just to get them out of the way of real work.

Planning

Premature Optimization – Don’t optimize code before you know it’s actually a bottleneck; it wastes time and adds complexity.
Parkinson’s Law – Work expands to fill whatever time you give it.
Ninety-Ninety Rule – The first 90% of a feature takes 90% of the time… and the last 10% takes another 90%.
Hofstadter’s Law – Everything takes longer than expected, even when you plan for it taking longer.
Goodhart’s Law – Once you turn a metric into a target, people start gaming it, and it stops meaning anything.
Gilb’s Law – If something matters, you can find a way to measure it – even if it seems fuzzy.

Quality

Boy Scout Rule – Always leave the code a little better than you found it.
Murphy’s Law – If something can go wrong, eventually it will.
Postel’s Law – Be strict about what you send out, lenient about what you accept in.
Broken Windows Theory – Small unfixed problems (bad code, sloppy decisions) invite more sloppiness – fix them early.
Technical Debt – Shortcuts you take now that slow you down later – like a loan you have to pay back with interest.
Linus’s Law – With enough people looking at code, bugs get found fast.
Kernighan’s Law – Debugging is harder than writing the code, so don’t write code so clever you can’t debug it.
Testing Pyramid – Write lots of fast unit tests, fewer integration tests, and very few slow UI tests.
Pesticide Paradox – Running the same tests over and over stops catching new bugs – you need to keep adding new ones.
Lehman’s Laws – Software that’s actually used has to keep changing, but there are limits to how much change it can absorb.
Sturgeon’s Law – Most of everything (code, products, ideas) is mediocre – that’s normal, not a crisis.

Architecture

Hyrum’s Law – If many people use your API, someone will eventually rely on behaviors that you never intentionally designed or promised.
Gall’s Law – Complex systems that work always started as simple systems that worked – you can’t design complexity from scratch.
Law of Leaky Abstractions – An abstraction tries to hide complexity from you, but sometimes the hidden complexity shows up anyway. For example: when you use get_users(), you don’t need to know how the database works – you just ask for the users. But if get_users() suddenly becomes very slow, you may have to look underneath and discover that it is running an inefficient database query. The database details that were hidden from you have now “leaked” through the abstraction.
Tesler’s Law – Every app has a baseline amount of complexity that can’t be removed – only moved around (to the code, the user, or someone else).
CAP Theorem – In a distributed system, you can only fully have two of: consistency, availability, and tolerance to network failures.
Second-System Effect – After a simple successful project, teams tend to over-engineer the “big” follow-up and bloat it.
Fallacies of Distributed Computing – Common wrong assumptions beginners make about networks (like “the network is reliable” – it isn’t).
Law of Unintended Consequences – Changing a complex system always produces surprises you didn’t plan for.
Zawinski’s Law – Every program keeps growing features until it can basically do email.

Scale

Amdahl’s Law – Parallelizing work only speeds things up as much as the parallelizable part allows – the serial part is a hard ceiling.
Gustafson’s Law – As problems get bigger, parallel processing can still deliver big speedups (a more optimistic counter to Amdahl’s).
Metcalfe’s Law – A network gets more valuable the more people join it – value grows roughly with the square of users.

Design

YAGNI – Don’t build a feature until you actually need it, not because you “might” someday.
DRY – Don’t repeat the same logic/knowledge in multiple places – one source of truth.
KISS – Keep designs as simple as they can possibly be.
SOLID Principles – Five design guidelines that make code easier to maintain and extend over time.
Law of Demeter – Objects should only talk to their direct neighbors, not reach through them to grab something else.
Principle of Least Astonishment – Software should behave the way people expect – don’t surprise them.

Decisions

Dunning-Kruger Effect – The less you know about something, the more confident you tend to feel about it.
Hanlon’s Razor – Don’t assume malice when carelessness or a mistake explains it just as well.
Occam’s Razor – The simplest explanation that fits the facts is usually the right one.
Sunk Cost Fallacy – Don’t keep doing something just because you already invested time/money in it – the past cost is gone either way.
Map Is Not the Territory – Your model or diagram of a system is not the actual system – it’s always a simplification.
Confirmation Bias – We naturally favor information that agrees with what we already believe.
Hype Cycle & Amara’s Law – We overestimate new tech’s impact short-term, and underestimate it long-term.
Lindy Effect – The longer something has already survived (a tool, a language), the longer it’s likely to keep surviving.
First Principles Thinking – Break a problem down to its most basic true facts, then rebuild your solution from there.
Inversion – Instead of asking “how do I succeed,” ask “how would this fail” – then avoid that.
Pareto Principle (80/20) – Roughly 80% of your problems come from 20% of the causes – find and fix those first.
Cunningham’s Law – The fastest way to get a correct answer online isn’t to ask a question – it’s to confidently post a wrong one.

Leave a Reply Cancel reply