Adams on infallibility#
The major difference between a thing that might go wrong and a thing that cannot possibly go wrong is that when a thing that cannot possibly go wrong goes wrong it usually turns out to be impossible to get at and repair.
Amdahl’s law#
The speedup of a system is limited by the portion of work that cannot be improved. Big wins in one stage mean little if the rest of the path stays slow.
Brooks’s law#
Adding manpower to a late software project makes it later. New people need ramp-up, and coordination cost grows faster than headcount.
Chesterton’s fence#
Don’t tear down a fence until you understand why it was put up. Reform after understanding, not before.
Conway’s law#
Organizations design systems that mirror their own communication structure. If you want a different architecture, change how people talk — or accept the org chart in the code.
Gell-Mann amnesia effect#
You spot nonsense in coverage of your own field — then turn the page and trust the same outlet on everything else.
Gall’s law#
A working complex system evolved from a working simple system. Complex systems designed from scratch rarely work — and can’t be patched into working.
Goodhart’s law#
When a measure becomes a target, it ceases to be a good measure.
Campbell’s law#
The more a quantitative social indicator is used for decision-making, the more it will be subject to corruption pressures — and the more it will distort the processes it was meant to monitor.
Hanlon’s razor#
Never attribute to malice that which is adequately explained by stupidity — or exhaustion, ambiguity, or a missing runbook.
Hofstadter’s law#
It always takes longer than you expect, even when you take into account Hofstadter’s law.
Hyrum’s law#
With enough users, every observable behavior of your system becomes a dependency — not just what you promised in the docs.
Jevons paradox#
Making a resource more efficient can increase total consumption. Cheaper cycles invite more work, not less demand.
Kernighan’s law#
Debugging is twice as hard as writing the code. If you write it as cleverly as possible, you are by definition not smart enough to debug it.
Occam’s razor#
Entities should not be multiplied without necessity. Prefer the simplest explanation that still fits the facts.
Overton window#
At any moment only a narrow band of ideas feels “acceptable.” The window moves — and what was radical becomes ordinary.
Parkinson’s law#
Work expands so as to fill the time available for its completion.
Postel’s law#
Be conservative in what you send, and liberal in what you accept. Robust interfaces tolerate sloppy inputs without becoming sloppy outputs.
Ringelmann effect#
As more people join a task, average individual effort tends to drop. More heads ≠ proportional output.
Second-system effect#
The successor to a small, successful system is often over-designed into an ambitious failure. Experience from v1 becomes a license to stuff everything into v2.
Shirky principle#
Institutions will try to preserve the problem to which they are the solution. Fixing the root issue can threaten the org built around managing it.
Segal’s law#
A person with one watch knows what time it is. A person with two is never sure. Conflicting sources create doubt, not clarity.
Twyman’s law#
Any figure that looks interesting or different is usually wrong. Spectacular data deserves suspicion before celebration.
The Beyoncé rule#
If you liked it, then you shoulda put a test on it. Wanted behavior only stays wanted if something enforces it.
The ETTO principle#
People and orgs continually trade efficiency against thoroughness. You can’t maximize both at once forever.
Tesler’s law#
There is irreducible complexity in a system. You can move it between user, designer, and implementation — you can’t delete all of it.
The law of leaky abstractions#
All non-trivial abstractions leak. Eventually you must understand the layer underneath.
The law of the instrument#
If all you have is a hammer, everything looks like a nail. Favorite tools warp problem framing.
The law of triviality#
Groups spend disproportionate time on easy cosmetic issues and under-discuss hard substantial ones. Bikesheds beat nuclear plants.
Principle of least astonishment#
Interfaces should behave the way users already expect. Surprise is a bug in design.
The Ulysses contract#
Bind your future self while you still have resolve — limits, checklists, and pre-commitments that survive weak moments.
The Unix philosophy#
Make each program do one thing well. Compose small sharp tools instead of one sprawling multipurpose beast.
YAGNI#
You aren’t gonna need it. Don’t build generality for imagined futures — wait until a real requirement shows up.
No maxims match that filter.