Gall's Law
A complex system that works evolved from a simple system that worked.
To an executive
Large programmes designed whole from scratch tend to fail. Starting with something small that works and growing it delivers value sooner with less risk.
To an engineer
Build the simplest working core first and prove it in real use. Extend it step by step instead of designing a complex system up front.
The idea
John Gall, an American paediatrician, first published General Systemantics in 1975, later known as Systemantics: a wry book about how systems behave and especially how they fail. Its best-known line has become Gall's Law: a complex system that works is invariably found to have evolved from a simple system that worked. The corollary is harsher: 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.
Successful architectures grow. A working core is extended step by step, and each step is proven in real use before the next.
Why it works
Real use teaches what design cannot. A running system exposes the actual load, data, edge cases and user behaviour. A design on paper can only guess at them.
Each step starts from something that works. When a small change fails, the cause is near and the system can fall back to its last working state. When a large design fails, nobody knows which of its many parts is wrong.
Complexity compounds. Interactions between parts grow faster than the number of parts. Adding them gradually lets each interaction be understood before the next arrives.
Where it applies
- New platforms and products, which should start as thin slices that work end to end.
- Large programmes, as an argument against big-bang delivery.
- Integration and data platforms, which work better when grown one connection at a time.
- Migrations, where a strangler-fig approach replaces one working piece at a time.
How to apply
- Find the smallest useful system that works end to end, with real users or real data.
- Get it into production early, even if it does very little.
- Grow it in small steps, each of which leaves a working system behind.
- Let evidence choose the next step: real usage, failures and feedback, not the original master plan.
Example scenario
An organisation designed an enterprise integration platform to connect two hundred systems, with a canonical data model agreed up front. After three years of design and build, it had not carried a single production message, and the canonical model was already out of date.
A second attempt started with two systems that needed to exchange orders, using a simple message format agreed by those two teams. It was live within weeks. The platform then grew to five systems, then fifty, with the shared conventions extracted from what had worked in practice.
Questions to ask
- What is the simplest version that works end to end, and when can it be live?
- Are we designing the final state before proving the first step?
- How do we grow safely from what works today?
When not to use it
- Problems that are understood in full and rarely change, where a careful upfront design may be cheaper than iterating.
- Systems where a partial version is unsafe, such as some safety-critical controls; there, growth happens in simulation and testing before anything goes live.
How it misleads you
Gall's Law is sometimes used to avoid any upfront design. A simple system still needs sound structure, clear boundaries and room to grow, or the "working simple system" becomes a tangle that cannot evolve. Start small, but think about which decisions will be hard to change later.
Further reading
Last reviewed · Suggest an improvement