Gall's Law: Complex Things That Work Were Never Built That Way

John Gall was a paediatrician who wrote a book about why systems fail. Buried in it is one sentence that has been quoted by engineers ever since:

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 word doing the work is invariably. This is not "usually better" or "a good practice." It is a claim that complex working systems are always found to have a history — that they were grown, not authored.

You can check this against things you know. The internet started as a handful of connected machines. Every large city grew from a settlement. Every big company was once a few people. It is genuinely difficult to name a complex system that works well and was built complete in one go.

Why building it all at once fails

The reason is not that from-scratch designers are less talented. Two structural problems defeat them regardless of skill.

You don't know the real requirements yet — and cannot. Before a system exists, requirements are guesses. Some are wrong, some are missing entirely, and a few of the loudest turn out not to matter. A simple working system tells you which is which, because people use it and their behaviour corrects your assumptions. A from-scratch design must guess everything up front and receives no correction until the whole thing is finished, when correcting is most expensive.

Failures give you no information. This is the part people underestimate. When one new piece is added to a working system and something breaks, you know where to look. When forty untested pieces go live at once and something breaks, the failure could be anywhere — including in interactions between pieces that are each individually fine. Debugging cost does not rise in proportion to the number of new parts; it rises much faster, because you have to consider the combinations.

There is a third reason that is quieter but often decisive. Working systems accumulate undocumented knowledge. Odd little behaviours that look like mess are frequently solutions to problems someone hit years ago and never wrote down. A from-scratch replacement discards all of it and rediscovers those problems one by one, in production, usually at the worst moment.

The rewrite trap

The most common way people meet this law is by ignoring it, and the pattern is consistent enough to predict.

A system has grown messy. It is hard to change, full of odd corners, and everyone agrees it is bad. Someone proposes a rewrite: same functionality, clean design, built properly this time with everything we have learned.

It sounds obviously correct, and it usually goes the same way. The rewrite takes far longer than estimated, because the old system did more things than anyone had catalogued — most of them undocumented, many of them load-bearing. Meanwhile the old system still needs maintaining, so the team is running two systems. And when the new one finally ships, it has fresh bugs of its own, because it is a large body of code that has never met reality.

This is technical debt reasoning applied at the wrong scale. And per Conway's Law, if the organisation that produced the original mess has not changed, the rewrite drifts back toward the same shape anyway.

The alternative that actually works is dull: change it in pieces, keeping it working the whole time. Replace one component. Verify. Replace the next. It is slower to plan and much faster to finish, mostly because you never enter the long period where nothing works and nobody can tell how far along you are.

How to use it when building something new

Start with something embarrassingly simple that genuinely works. Not a prototype, not a mock-up — a real thing that does one real task end to end, however small. A working system for one user beats a design document for a thousand.

Add one thing at a time, and keep it working after each addition. The discipline is that the system is never broken for long. If it is broken for three months, you have accidentally started a from-scratch build.

Let usage tell you what to build next. The requirements you discover from a working system are worth much more than the ones you imagined before it existed, because they come from behaviour rather than speculation.

Be suspicious of any plan whose first working version arrives at the end. That is the shape Gall's Law warns about, whatever it is called internally.

Before removing something odd, find out why it exists. This is Chesterton's fence, and it pairs with Gall's Law naturally: grown systems encode fixes to problems you have not met yet. "I can't see why this is here" is weak evidence that there is no reason.

There is a fair limit to state. Sometimes the existing system genuinely cannot be evolved — the foundation is wrong in a way no incremental change reaches, or it is built on something that no longer exists. Rewrites are occasionally correct. The law does not say never; it says the from-scratch route has a much worse success rate than its advocates expect, and that expecting to be the exception is itself the most common symptom.

The safest version of ambition is a small thing that works, changed a great many times.