DivineForge
Essay
13 Engineering Laws Every Builder Should Know
Named principles that explain why software systems and organisations behave the way they do.
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 → |