These laws and heuristics come up most where engineering leadership, architecture, and delivery meet. The ten below are in ranked order for that work. Each entry gives the idea, what to do about it, and where to read more.
Ranked laws
Conway’s Law
A system’s design reflects the communication structure of the organization that builds it, informal working relationships included. Follow one feature from request to release, find the handoff where decisions wait or information gets lost, and clarify that dependency before redrawing teams. See Team Topologies.
Read: Mel Conway: How Do Committees Invent? · Martin Fowler: Conway’s Law
Goodhart’s Law
Optimizing a proxy can weaken its link to the result it was meant to represent, with or without deliberate gaming. Pair every speed measure with a quality signal such as escaped defects or rework, and use both to investigate the system.
Read: Manheim and Garrabrant: Categorizing Variants of Goodhart’s Law · Google SRE: Monitoring Distributed Systems
Gall’s Law
Working complex systems grow from simple systems that worked. Pick a first slice that crosses enough of the real workflow to test the risky assumptions, and decide before building what evidence permits expansion and how to reverse the change. See Modernize safely, one slice at a time.
Read: John Gall: Systemantics · Martin Fowler: Strangler Fig
Brooks’s Law
Adding people to a late project can slow it at first, because experienced engineers must explain the system, review unfamiliar work, and integrate more changes. Check whether the delay comes from capacity, a dependency, or an open decision, and give newcomers separable work with a named reviewer.
Read: Fred Brooks: The Mythical Man-Month · Software Engineering at Google: Knowledge Sharing
Hyrum’s Law
With enough consumers, every observable behavior of an interface becomes something someone depends on. Before changing behavior, find the consumers, test the change against how they actually use it, and give the transition an owner and a monitoring window.
Read: Hyrum Wright: Hyrum’s Law · Software Engineering at Google: What Is Software Engineering?
Leaky abstractions
Abstractions hide details that still matter when performance, failures, or edge cases cross the boundary. For each important one, know what it promises, which identifiers and errors reveal the underlying operation, and what can safely be retried.
Read: Joel Spolsky: The Law of Leaky Abstractions
Amdahl’s Law
For a fixed workload, the serial fraction s caps the speedup from N workers at 1 / (s + (1 − s) / N). Measure the serial fraction first, then compare adding workers with shrinking the serial work. For teams, treat it as an analogy only.
Read: NVIDIA: Strong Scaling and Amdahl’s Law
Bus factor
The bus factor is the smallest number of people whose absence would seriously disrupt a project. Test it task by task: have a second person perform the critical task in a safe rehearsal while the expert watches, then fix the runbook wherever they needed help.
Read: Software Engineering at Google: How to Work Well on Teams
Technical debt
Make the carrying cost of deferred engineering work visible, and prioritize improvements by the friction they remove. Record it like a decision: see Name the debt.
Ringelmann effect
Average individual performance can fall as a group grows, through coordination losses and through reduced effort when people assume others will contribute. When a growing group stalls, give each decision an owner and find where work waits on another person before blaming effort.
Read: Ingham and colleagues: Group Size and Group Performance
Law pairs
Some laws are most useful read together, each checking the other.
Hofstadter and Parkinson
Work takes longer than you expect, and work expands to fill the time available, so slack padded into every task tends to get used. Estimate each task honestly, give a likely date and a date you would commit to, and hold one visible buffer at the end.
Read: Buehler, Griffin and Ross: Exploring the planning fallacy · Eliyahu Goldratt: Critical Chain
Postel and Hyrum
Accepting sloppy input feels robust until clients depend on the sloppiness, and then the tolerance can’t be withdrawn without breaking someone. Validate strictly at the boundary, write any variation you tolerate into the contract, and warn clients before tightening. See Translate at the boundary.
Read: Jon Postel: RFC 761, section 2.10 · Thomson and Schinazi: RFC 9413, Maintaining Robust Protocols
Gilb and Goodhart
A rough measure beats no measure, and any measure used as a target can drift from what it was meant to show. Start with something cheap, say what it misses, watch a counterweight beside it, and retire it when behavior bends toward the number.
Read: Tom Gilb: How to Quantify Quality · DeMarco and Lister: Peopleware
Gall and the second-system effect
A replacement tends to absorb every idea deferred from the first system, and complex designs built from scratch rarely work. Replace one flow at a time, match the old behavior before improving it, and measure progress by what the old system no longer has to do.
Read: Fred Brooks: The Mythical Man-Month · Martin Fowler: Strangler Fig
Murphy and Hanlon
Anything that can go wrong eventually will, and a mistake explains most failures better than malice does. In an incident review, build the timeline first, ask what made the mistake easy, and give every fix an owner and a date.
Read: Google SRE: Postmortem Culture · Sidney Dekker: The Field Guide to Understanding ‘Human Error’
Linus and Ringelmann
More reviewers can find more bugs, or each can assume someone else looked. Name one accountable reviewer with the right expertise, keep changes small enough to read carefully, and let automated checks cover the mechanical parts. See Verification at AI volume.
Read: Eric S. Raymond: The Cathedral and the Bazaar · Meneely and Williams: An Empirical Study of Linus’ Law
Amara and Lindy
We overestimate a new technology’s effect in the short run and underestimate it in the long run, while durable layers such as data, interfaces, and SQL keep outlasting predictions. Invest steadily in the foundations, run small reversible experiments at the edges, and revisit the bets on a schedule.
Read: IEEE Computer Society: Amara’s Law and Its Place in the Future of Tech · Nassim Nicholas Taleb: Antifragile
Little’s Law
In a stable system, average cycle time equals work in progress divided by throughput. Starting more work doesn’t raise throughput by itself, so at the same throughput it only makes everything wait longer: the arithmetic behind WIP limits. It describes averages, so forecast a single delivery date from recent throughput, as a range. Value stream mapping shows where the waiting happens, and APEL caps active work for the same reason.
Read: John D. C. Little: A Proof for the Queuing Formula L = λW · Daniel Vacanti: Actionable Agile Metrics for Predictability
Read critically
This collection mixes formal results, observations, and heuristics. Little’s and Amdahl’s laws are formal results; most of the others are observations from experience. Use each within its assumptions. A memorable name is a prompt to investigate, not evidence that an explanation is correct.
Reading source: Laws of Software Engineering, Dr. Milan Milanović. The notes here are independent commentary.