13 Engineering Laws Every Builder Should Know

These laws come up repeatedly in real work. They are not theory — they are observed reality, named and documented by people who built things and paid attention to what happened.

Each law has a satire article showing what happens when it is ignored in a fictional enterprise. Follow the link in the Scenario column to read the story.

---

Law	Principle	Scenario
Conway's Law	Architecture mirrors the communication structure of the org that builds it.	Read →
Brooks' Law	Adding people to a late project makes it later.	Read →
Gall's Law	Complex systems can only evolve from simple ones that already worked.	Read →
Hyrum's Law	With enough users, all observable behaviours become dependencies — regardless of the contract.	Read →
Postel's Law	Be conservative in what you send, liberal in what you accept.	Read →
Parkinson's Law	Work expands to fill the time available.	Read →
Goodhart's Law	When a measure becomes a target, it ceases to be a good measure.	Read →
Law of Leaky Abstractions	All non-trivial abstractions leak. The layer below is deferred cost, not optional knowledge.	Read →
Hofstadter's Law	It always takes longer than you expect — even when you account for this law.	Read →
Chesterton's Fence	Don't remove what you don't understand. Find out why it's there first.	Read →
Amdahl's Law	Speedup from parallelism is bounded by the sequential fraction.	Read →
Wirth's Law	Software gets slower faster than hardware gets faster.	Read →
Principle of Least Astonishment	A system should behave the way users expect. Surprise is almost always a bug.	Read →