---
title: Software Laws
synced_from_vault: true
vault_source: 03-living-docs/patterns/Software-Laws.md
public: true
type: index
tags:
  - pattern
  - systems-thinking
  - technical-strategy
  - architecture
  - management
created: 2026-02-18T00:00:00.000Z
origin: >-
  Curated from pipeline-skills design-priorities.md + classical software
  engineering literature
---

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](/patterns/galls-law) |
| **Goodhart's Law** | When a measure becomes a target, it stops being a good measure | [Goodharts-Law](/patterns/goodharts-law) |
| **Amdahl's Law** | Sequential bottlenecks limit maximum speedup from parallelization | [Amdahls-Law](/patterns/amdahls-law) |
| **Conway's Law** | Org structure → system architecture — you can't fix one without fixing the other | [Conways-Law](/patterns/conways-law) |
| **Chesterton's Fence** | Understand why something exists before removing it | [Chestertons-Fence](/patterns/chestertons-fence) |
| **Lehman's Laws** | Software complexity increases unless actively reduced — there's no steady state | [Lehmans-Laws](/patterns/lehmans-laws) |
| **Postel's Law** | Be conservative in output, liberal in input — across code and communication | [Postels-Law](/patterns/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](/patterns/doorman-fallacy) — closely related to Chesterton's Fence (misunderstanding value vs. misunderstanding reason)