Gall's Law
Every complex system that works started as a simple system that worked. Rebuilding from scratch almost always fails — because you lose everything the old system had quietly learned to handle.
Why PMs should care
Here's Gall's original quote, worth keeping in your head:
'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.'
This is the answer to every 'let's take a quarter and build the ideal architecture' conversation, every 'v2 from scratch' proposal, and every new backend that's going to replace the messy legacy one with something clean.
These rewrites fail far more often than people expect. The reason is simple: the old system isn't messy because the team was careless. It's messy because over the years it quietly absorbed thousands of small fixes, each one a response to a real problem — a regulator's letter, a rare customer case, an outage at 3am. The team doesn't even remember most of these fixes are there. A rewrite starts from a clean slate, and a clean slate doesn't know about any of them. You only find out what was missing when it breaks in production.
The practical rule: evolve, don't rebuild. If you genuinely have to rebuild something, do it piece by piece, in production, with the old version still running alongside the new one. Retire the old parts only when the new ones have clearly earned their place.
Example in product work
A platform team proposes replacing the legacy KYC backend with a new service built from scratch — clean architecture, modern language, proper event-driven design. Estimate: two quarters, one team.
The old backend is a tangled mess of six years of regulatory patches, half-documented integrations, and edge-case handling nobody fully understands.
- Quarter 2 in: the new service handles 87% of cases cleanly. The remaining 13% turns out to contain every genuinely hard problem the old system had silently solved.
- Quarter 3: the team is reverse-engineering the old system's behaviour for each edge case.
- Quarter 4: the new system is shipped, runs in parallel, and still produces different results from the old one in rare cases that everyone hoped wouldn't matter.
- 18 months later: the old system is still running because nobody's confident enough to turn it off.
The correct version of this project was to refactor the old system incrementally, modernising one module at a time with test coverage, over two years — less exciting, ships faster, and actually works.
What to do when you see it
- Messy legacy systems are usually that way because they've quietly solved hundreds of real problems over the years.
- A rewrite starts from a clean slate — and the clean slate doesn't know about any of those problems until they break.
- Prefer evolving the existing system over replacing it. It's less glamorous and ships sooner.
- If you must rebuild, run old and new side by side for a long time. Turn off the old one only when you've stopped being scared to.
Sources & further reading
- Gall's Law — Personal MBAJosh Kaufman's overview, framing Gall's Systemantics observations in business and systems-design terms.
- Gall's Law and Startups — freeCodeCampA practical explainer on why complex systems that work always evolve from simpler ones that worked, applied to startups.