Software Laws
Hub note for seven classical laws that govern code, architecture, teams, and organizations. Each law has its own atomic note — this page covers why they matter as a set and how they interact.
The Laws
| Law | Core Principle | Atomic Note |
|---|---|---|
| Gall’s Law | Complex systems evolve from simple ones that worked — never design from scratch | Galls-Law |
| Goodhart’s Law | When a measure becomes a target, it stops being a good measure | Goodharts-Law |
| Amdahl’s Law | Sequential bottlenecks limit maximum speedup from parallelization | Amdahls-Law |
| Conway’s Law | Org structure → system architecture — you can’t fix one without fixing the other | Conways-Law |
| Chesterton’s Fence | Understand why something exists before removing it | Chestertons-Fence |
| Lehman’s Laws | Software complexity increases unless actively reduced — there’s no steady state | Lehmans-Laws |
| Postel’s Law | Be conservative in output, liberal in input — across code and communication | Postels-Law |
| Zawinski’s Law | Every program attempts to expand until it can read mail; those that can’t are replaced by ones that can | Zawinskis-Law |
Why These Matter
These aren’t academic curiosities — they’re the laws I keep running into when building systems, leading teams, and making technical decisions. Each one has bitten me or someone I’ve worked with. They apply at every level: code, architecture, team design, organizational structure.
How the Laws Reinforce Each Other
| Interaction | What Happens |
|---|---|
| Goodhart + Amdahl | The fastest way to speed up a system is to remove quality checks (Amdahl). But quality checks defend against metric gaming (Goodhart). Tension: speed vs. correctness. |
| Conway + Postel | Conway says boundaries shape systems. Postel says systems should be tolerant across boundaries. Together: draw boundaries carefully (Conway), but don’t couple tightly across them (Postel). |
| Gall + Lehman | Gall says start simple and evolve. Lehman says evolution creates complexity. Together: add one thing at a time (Gall), periodically simplify (Lehman). |
| Chesterton + Conway | Chesterton says understand constraints before removing them. Conway says boundaries shape what you can see. Together: make existing constraints visible across boundaries. If a boundary hides a fence, someone will unknowingly tear it down. |
| Goodhart + Chesterton | A metric exists for a reason (Chesterton). But optimizing for it destroys its value (Goodhart). The metric is a fence — understand why it was built, but don’t over-rely on it. |
The Management Layer
These laws aren’t just about code. They’re about any complex system — including organizations:
| Law | Code Implication | Organization Implication |
|---|---|---|
| Postel’s | Strict APIs, tolerant parsers | Precise commitments, generous interpretation |
| Conway’s | Org chart = architecture | Team structure is the first architectural decision |
| Amdahl’s | Optimize the bottleneck | Adding headcount doesn’t speed up coordination-bound work |
| Goodhart’s | Metrics get gamed | Measure what matters, pair metrics with counter-metrics |
| Gall’s | Evolve, don’t rewrite | Incremental process change beats big-bang transformation |
| Lehman’s | Complexity grows unless fought | Invest in simplification or drown in entropy |
| Chesterton’s | Understand before removing | New leaders: learn before you “fix” |
Origin
Curated from the design priorities document in the pipeline-skills project (Dave’s AI agent pipeline), where these laws were applied specifically to agent-orchestrated software delivery. Extracted and generalized here as a reference for technical strategy, management philosophy, and systems thinking broadly.
The pipeline-skills framing is valuable because it shows these laws aren’t abstract — they govern real design decisions about where to put human checkpoints, how to structure stage boundaries, when to automate, and how to fight entropy.
Cross-References
- Doorman-Fallacy — closely related to Chesterton’s Fence (misunderstanding value vs. misunderstanding reason)