Laws and Principles – tdonker.nl

^{Published: 08.01.2026}

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 enough people use your API, someone will depend on even its accidental quirks – so “internal” behavior isn’t safe to change.
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 – Every abstraction hides details, but eventually those details leak through and you have to deal with them anyway.
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.