← Patterns

Gall's Law

CategorySystems Thinking / Technical Strategy
SourceJohn Gall, Systemantics (1975)
Surfaced in OSFeb 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).


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