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.
Wisdoms, aphorisms, and pointed observations — short principles I keep coming back to when talking about software, systems, and ways of working.
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.
Don’t tear down a fence until you understand why it was put up. Reform after understanding, not before.
You spot nonsense in coverage of your own field — then turn the page and trust the same outlet on everything else.
A working complex system evolved from a working simple system. Complex systems designed from scratch rarely work — and can’t be patched into working.
When a measure becomes a target, it ceases to be a good measure.
Never attribute to malice that which is adequately explained by stupidity — or exhaustion, ambiguity, or a missing runbook.
It always takes longer than you expect, even when you take into account Hofstadter’s law.
With enough users, every observable behavior of your system becomes a dependency — not just what you promised in the docs.
Making a resource more efficient can increase total consumption. Cheaper cycles invite more work, not less demand.
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.
Entities should not be multiplied without necessity. Prefer the simplest explanation that still fits the facts.
At any moment only a narrow band of ideas feels “acceptable.” The window moves — and what was radical becomes ordinary.
Work expands so as to fill the time available for its completion.
As more people join a task, average individual effort tends to drop. More heads ≠ proportional output.
A person with one watch knows what time it is. A person with two is never sure. Conflicting sources create doubt, not clarity.
If you liked it, then you shoulda put a test on it. Wanted behavior only stays wanted if something enforces it.
People and orgs continually trade efficiency against thoroughness. You can’t maximize both at once forever.
There is irreducible complexity in a system. You can move it between user, designer, and implementation — you can’t delete all of it.
All non-trivial abstractions leak. Eventually you must understand the layer underneath.
If all you have is a hammer, everything looks like a nail. Favorite tools warp problem framing.
Groups spend disproportionate time on easy cosmetic issues and under-discuss hard substantial ones. Bikesheds beat nuclear plants.
Interfaces should behave the way users already expect. Surprise is a bug in design.
Bind your future self while you still have resolve — limits, checklists, and pre-commitments that survive weak moments.
Make each program do one thing well. Compose small sharp tools instead of one sprawling multipurpose beast.