---
title: Gall's Law
synced_from_vault: true
vault_source: 03-living-docs/patterns/Galls-Law.md
public: true
type: pattern
tags:
  - pattern
  - systems-thinking
  - architecture
  - process
aliases:
  - Gall's Law
created: 2026-02-21T00:00:00.000Z
origin: 'John Gall, *Systemantics* (1975); applied in pipeline-skills design priorities'
---

| | |
|-|-|
| **Category** | Systems Thinking / Technical Strategy |
| **Source** | John Gall, *Systemantics* (1975) |
| **Surfaced in OS** | Feb 18, 2026 (atomized Feb 21) |

---

## Core Concept

> "A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work."

You can't design a complex working system. You can only *grow* one — by starting with a simple system that works and evolving it incrementally. Every attempt to build a complete system from scratch produces something that doesn't work and can't be fixed by patching.

---

## Where It Applies

### Architecture
Never do a ground-up rewrite. Evolve from what works. The Hugo Pattern at OrangeQC was a Gall's Law violation — massive isolated rewrite designed from scratch, never shipped.

### Process
Don't introduce a complete development process on day 1. Start with one practice (standups, or visible kanban, or code review), get it working, add the next. The OrangeQC turnaround followed this — mandatory standups first, then visible kanban, then integration tests, evolved over months.

### Pipeline/Tooling
Each new capability should be an incremental evolution of something that already works. If a new feature can't ship as a standalone improvement, it's scoped wrong.

### Personal Systems
This OS itself follows Gall's Law — started with `_current.md` and grew structure as needed. "We don't over-engineer domains we haven't entered yet."

---

## The Rewrite Trap

Engineers love rewrites because they imagine the clean-slate system. But clean-slate systems don't have the accumulated knowledge of why the old system was shaped the way it was. Every "ugly" workaround in a working system is load-bearing until proven otherwise (see: [Chesterton's Fence](/patterns/chestertons-fence)).

---

## The Test

Before adding complexity, ask: "Does the current simpler system work?" If yes, evolve it. If no, fix it before adding more.

---

## Cross-References

- [Software-Laws](/patterns/software-laws) — hub for all seven laws and how they interact
- [Lehman's Laws](/patterns/lehmans-laws) — complementary: Gall says start simple, Lehman says evolution creates complexity. Together: add one thing at a time, periodically simplify.
- [Chesterton's Fence](/patterns/chestertons-fence) — the workarounds in working systems are evidence, not waste
- [Graceful-Self-Extension](/patterns/graceful-self-extension) — the mechanism by which Gall's Law operates: systems grow by encountering what they can't handle