Every ambitious rebuild starts the same way: a team, frustrated with a messy system, designs a grand new one that handles every case elegantly from day one. John Gall explained in 1975 why these almost always fail. A working complex system, he observed, is invariably found to have grown from a working simple one, and a complex system designed from scratch never works.
Key Takeaways
- Gall's Law: a complex system that works evolved from a simple system that worked (Gall's Law).
- A complex system designed from scratch never works and can't be patched into working (John Gall).
- It comes from John Gall's 1975 book Systemantics (Systemantics).
- The practical rule: start simple, get it working, and grow complexity in steps.
The Law
John Gall, a pediatrician who wrote about how systems behave, stated it plainly in Systemantics: "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 made to work. You have to start over, beginning with a working simple system" (John Gall). He wrote it during an era of grand, over-ambitious system projects that kept collapsing under their own scope (Gall's Law).
The claim is stronger than "start small." It's that complexity has to be grown, not designed, because a working system encodes a thousand small adaptations to reality that no upfront design can anticipate. Skip the simple, working stage and the complex version has no foundation of validated assumptions to stand on.
Why Big-Bang Designs Fail
A from-scratch complex system fails because it front-loads all its risk. Every assumption is untested, every interaction unproven, and they all have to be right at once for the thing to work, which they never are. An evolved system, by contrast, is never more than one small, testable step ahead of something that already worked, so problems surface one at a time against a known-good baseline. This is the same reason big rewrites fail: the rewrite is a from-scratch complex system, and it inherits none of the hard-won corrections baked into the old one.
| From-scratch complex system | Evolved from simple |
|---|---|
| All risk front-loaded | Risk taken one step at a time |
| Every assumption untested | Each step validated before the next |
| Works only if everything is right | Always near a known-good baseline |
| Usually collapses | Usually survives |
A Concrete Version
A team decides to replace their tangled billing system with a beautifully-designed new platform that handles every pricing model, currency, and edge case they can imagine, all built before launch. Eighteen months in, it still doesn't work end-to-end, because the interactions between all those features produce surprises nobody designed for, and there's no simpler working version to fall back to. A team that instead shipped the simplest billing that worked, then added one pricing model at a time, would have had a working system the whole way and grown the complexity only as reality demanded it.
The Honest Counterpoint
Gall's Law isn't a licence to avoid all design or to never plan ahead. "Start simple" taken naively can produce a simple system that was architected into a corner, one that can't evolve toward the complexity you'll clearly need, which is its own failure. The law argues for evolutionary growth from a working base, not for thoughtlessness: you still design, you still anticipate, you just validate each increment against reality instead of betting everything on a grand plan that meets the world for the first time on launch day. Some genuinely novel systems also have irreducible complexity that a toy version can't demonstrate. The default, though, is evolution.
What This Means for Teams
Gall's Law is one of the most reliable predictors of whether an ambitious project will ship. Senior engineers have usually watched a from-scratch grand design collapse, so they instinctively push to get the simplest useful version working first and grow from there, which is the same judgment behind resisting premature microservices and big rewrites. That bias toward evolution over big-bang design is part of what we screen for in how to verify a senior engineer. See available engineers.
Frequently Asked Questions
What is Gall's Law?
John Gall's 1975 observation that a complex system that works is always found to have evolved from a simple system that worked, and that a complex system designed from scratch never works and can't be patched into working.
Why do from-scratch complex systems fail?
Because they front-load all their risk: every assumption is untested and they all must be right at once. An evolved system stays close to a known-good baseline, so problems surface one at a time.
Does this mean I shouldn't design ahead?
No. It argues for growing complexity from a working base, not for skipping design. You still plan and anticipate; you just validate each increment against reality rather than betting everything on a grand launch-day debut.
How does it relate to rewrites?
A big rewrite is a from-scratch complex system, so Gall's Law predicts it will struggle. Evolving the existing system, or strangling it piece by piece, respects the law where a clean-slate rebuild defies it.
The Bottom Line
Complexity that works is grown, not designed: a working complex system always traces back to a working simple one, and grand from-scratch designs collapse under their own untested scope. Ship the simplest thing that works, then add complexity one validated step at a time. Evolution beats the big bang, in billing systems and browsers alike.
Roberto Espinoza is CEO of Ruzora, which helps US startups hire pre-vetted senior LATAM engineers, with a vetted shortlist in 72 hours. See available engineers.
