Should I Buy It?
Every complex system that works has invariably 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 have to start over with a simple working system.
Origin
John Gall (1925–2014) was an American pediatrician and systems theory enthusiast. In General Systemantics: How Systems Work and Especially How They Fail (1975), he compiled decades of observations on failing systems across all domains — medicine, technology, bureaucracy, and engineering.
His central conclusion, reformulated in The Systems Bible (2002):
“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 have to start over with a working simple system.”
The book is written with humor and cynicism, but the empirical observation holds.
The Theory
Gall’s Law identifies a fundamental asymmetry between evolution and design: evolutionary systems accumulate complexity in successive layers, each validated before the next is added. Systems designed upfront as complex never pass through this reality filter.
A simple working system has something irreplaceable: proof that it works. It can then be enriched with one additional layer, tested in turn, and so on. Each step remains anchored in something that has proven its value.
By contrast, a system conceived all at once in its full complexity accumulates untested assumptions. When it fails — and it will fail — you cannot tell which layer is broken. Patching is useless: the problems are structural, not superficial.
The law applies universally: software systems, organizations, work processes, automation workflows.
In Practice
Evolutionary successes: The World Wide Web started as a hyperlink system between academic documents. Blogs emerged from simple HTML pages. Unix began as a single researcher’s project. Each grew through successive validated layers.
Design failures: CORBA — a complex technical specification from the start, never truly adopted. Large government IT programs built on 500-page requirement documents, delivered five years later into a changed world.
Personal application: Build a V1 of a simple tool that solves one precise problem. Validate that it works. Add one layer. Validate. Repeat. Never skip the “validate that it works” step.
Gall’s Law is an argument for agile development, the MVP, and iterative methods — not as ideology, but because empirically it is the only way to build systems that actually work.
Nuances and Limits
The law is descriptive, not prescriptive. It describes how working systems are built, not how systems should ideally be designed.
It does not say to stay simple forever — it says complexity must be acquired progressively, starting from a working base.
Gall’s Law complements Kelly Johnson’s KISS principle (Keep It Simple, Stupid): KISS prescribes simplicity as a design goal, Gall observes it as an empirical condition of success. Both converge on the same practical recommendation: start simple, validate, then cautiously add complexity.
The law does not apply in every context — some systems must be designed in full before they can function (an aircraft, a bridge). But in organizational, software, and process systems, Gall’s observation holds remarkably well.
Sources: Wikipedia — John Gall · Systemantics