Gall's Law: Why Complex Systems Must Evolve

The whiteboard looks magnificent. Fourteen services, a message bus, a schema registry, three data stores chosen for three access patterns, a caching tier, an event-sourcing spine, and clean boundaries drawn around every one of them. Nobody has written a line of code yet, but the diagram already anticipates the load you expect in year three, the team you plan to hire, and the integrations a customer might one day ask for. It is the system done right, up front, before any of the mess creeps in. Eight months later three of the fourteen services do nothing, two of the boundaries are wrong, the message bus is carrying calls that should have been function invocations, and the team that drew the diagram is spending its days keeping the scaffolding standing rather than shipping the thing customers asked for. The design was not stupid. It was just built the wrong way round, and there is a 1975 rule of thumb called Gall's law that predicted exactly this.

Gall's law is one of the most quietly useful ideas in systems design because it tells you not what to build but in which order to build it. Every summary you will find states it in one line and moves on to the World Wide Web and Facebook as tidy success stories. What none of them give you is the thing you need at the moment the grand architecture is being drawn: a way to tell a simple system that will actually grow into the complex one you want from a small thing that is simply too small to work, and a way to keep the reasons behind each layer of complexity from evaporating as the system evolves. Here is what Gall's law is, why designed-from-scratch complexity fails so reliably, the big-bang systems that prove it, how to apply it without misreading it, and the part of the law that nobody maintains.

What is Gall's law?

Gall's law states that a complex system that works is invariably found to have evolved from a simple system that worked, and that a complex system designed from scratch never works and cannot be patched to make it work; you have to start over with a working simple system. John Gall, a pediatrician rather than a software engineer, published it in his 1975 book Systemantics: How Systems Really Work and How They Fail. The book was a wry field guide to why large systems behave in ways nobody intended, and the law is its most durable line.

The claim is stronger than "start small." It is a claim about causality. Working complex systems are not merely often grown from simple ones; Gall's argument is that grown-from-simple is the only path that reliably produces a working complex system at all. The from-scratch route does not just carry more risk. It fails as a category, because the complexity you are trying to specify up front contains too many interactions you have not yet observed, and you cannot design correctly against interactions you have never seen. A simple system that runs in front of real users is a machine for discovering those interactions one at a time, at a survivable cost. A grand design discovers them all at once, at the end, when the cost of being wrong is highest. Growing a system this way also depends on tolerant interfaces between its parts, because each incremental change introduces small mismatches that a brittle, strict boundary would turn into a breakage.

The word doing the heavy lifting is "worked." Gall's law is not "start with something small," because a small thing that does not actually do the job is not a seed, it is a fragment. The seed has to be a system that genuinely performs its core function end to end for real users, however few features it has. Josh Kaufman's Personal MBA summary puts the same point plainly: no pre-manufactured parts or grand plans, just a working simple system you extend. That distinction is where most misapplications go wrong, and it is worth its own section below. If you are starting a system today, the highest-leverage habit is writing down the one job the first version must truly do before you let anything else in. Try Scribelet free and keep that boundary somewhere it stays visible as the system grows.

Why designed-from-scratch complex systems fail

The intuitive objection to Gall's law is that surely a smart enough team, given enough analysis, can design the complex system correctly the first time. The reason they cannot is not a shortage of intelligence. It is that a complex system's behavior is dominated by the interactions between its parts, and the number of interactions grows far faster than the number of parts. A design document can enumerate the parts. It cannot enumerate what happens when part seven's slow path collides with part eleven's retry policy under a load pattern no one anticipated, because that behavior does not exist until the parts are running together against reality.

So a from-scratch complex system is a large bet placed entirely on assumptions, and the assumptions are validated only at the very end, when everything is wired together and switched on. Every one of them that turns out wrong has to be unwound through the whole structure that was built on top of it. This is why a failed big-bang system cannot simply be patched: the flawed assumptions are load-bearing, and the fixes for them contradict the architecture that assumed them. Starting over with a working simple system is not defeatism. It is the only move that lets you validate the risky assumptions early, one at a time, while each is still cheap to be wrong about. If you are about to commit a team to a large up-front design, the cheapest safeguard is a written record of which assumptions the design depends on, so you can watch them survive contact with reality instead of discovering their failure buried three layers deep. Try Scribelet free and keep the "what this design is betting on" list somewhere it stays honest.

Gall's law examples: the big-bang systems that failed

The success stories get repeated everywhere, so they are the least useful evidence. The World Wide Web began as a way to share physics papers. Facebook began as a directory for one campus. Unix, Amazon, and nearly every durable platform grew from something small that worked. The more instructive cases are the from-scratch systems built by capable, well-funded teams that never reached a working complex state, because they show the failure mode Gall's law names rather than the survivorship it flatters.

None of these failed for lack of talent or money, and that is the point. They failed because the whole bet came due at the end, and there was no simple working system underneath to fall back to when it did. Each one was eventually replaced, when it was replaced at all, by something that started smaller and grew. The pattern of over-reaching on a single planned build has a close relative worth knowing: the second-system effect, where a team's confidence from a successful first version drives them to over-engineer its replacement. Gall's law is the general principle; the second-system effect is the specific trap that springs when the from-scratch system is version two.

What "a simple system that works" actually means

The most common way to misuse Gall's law is to hear "start simple" and ship something that is small but does not actually work. A login screen with no backend, a demo that only handles the happy path, a prototype that falls over the moment a real user touches it: none of these is the seed Gall's law describes, because none of them works in the sense that matters. The seed is a system that performs its core job, end to end, for real users, with nothing faked behind the curtain. It can be missing almost every feature. It cannot be missing the actual function.

The thinnest honest version of this is a single path built all the way through every layer of the system rather than one layer built out across every feature. Building that first, before widening it, is a thin slice that runs end to end, a well-known technique in its own right, but the deeper point for Gall's law is the test it forces you to pass: does this small thing genuinely do the job, or does it only look like it does? Use a short checklist before you call something a working seed.

• It handles a real request from a real user, all the way through, with no step stubbed or mocked in production.
• It does one genuinely useful job, not a fragment of several.
• Someone outside the team could use it and get a correct result, even if the result is plain.
• Its failure modes are visible, not hidden behind a demo script.
• You could grow the next feature onto it without tearing it down.

If a candidate seed fails these, the answer is not to add architecture. It is to make the small thing actually work first, because Gall's law only promises evolution from a system that already runs. A technical spec that names the one path the first version must carry end to end, and explicitly defers everything else, is a good way to keep "simple" from sliding into "incomplete."

Gall's law vs the second-system effect vs Conway's law

Gall's law travels with two other systems-design laws, and teams often blur them because all three touch architecture and complexity. They answer different questions, and holding them apart makes each one sharper.

The three interlock. Gall tells you to evolve rather than design-from-scratch; the second-system effect is exactly the temptation to ignore Gall when you rebuild something you already understand; and Conway's law warns that whatever you grow will take the shape of your team boundaries whether you intend it or not. A team that internalizes all three starts small (Gall), resists the urge to make version two a grand rewrite (second-system effect), and watches its org chart so the evolving architecture does not calcify around an accident of who talks to whom (Conway). This is the kind of call worth making with a decision framework rather than by whoever is most attached to the clean-slate diagram.

How to misread Gall's law

Because the law is stated so starkly, it collects misreadings, and each one turns a useful principle into an excuse. Naming them is the cheapest way to keep the law from being weaponized in a design review.

The through-line is that Gall's law constrains the order of construction, not the ambition of the destination. You are allowed to want the complex system. You are not allowed to reach it by designing the whole thing before anything runs.

The diagram is the whole argument in one frame. The evolutionary path validates each layer against reality before adding the next, so a wrong assumption is caught while it is cheap. The big-bang path stacks every assumption on top of the others and tests them all at once at the end, where a single load-bearing mistake takes the whole structure down with it.

The part nobody maintains: why each layer of complexity was added

Here is the piece the one-line summaries miss, and it is the piece that decides whether an evolved system stays healthy or rots. Gall's law gets you a working complex system by adding one justified layer at a time. But each of those layers was added for a reason, and the reason almost never gets written down next to the layer.

Think about what a mature, evolved system actually contains. The retry count that is three because of one flaky downstream that has since been fixed. The queue that exists because of a traffic spike in a launch nobody remembers. The service boundary that made sense when two different teams owned the two halves. The config flag added for a customer who churned two years ago. Every one of those was a sound evolutionary step at the time, a small addition of complexity justified by a real constraint, and by the time anyone else observes it, Hyrum's law has usually already turned the accidental shape of it into something a caller depends on, whether or not it was ever meant to be permanent. But the constraint lived in someone's head, a chat thread, or a ticket that is now unfindable, while the complexity lives on in the running system. Over time the system accumulates layers whose original reasons have decayed, and evolution quietly degrades into accretion: you keep adding, because you can no longer tell which of the existing layers are load-bearing and which are scars from problems that no longer exist. That is the moment a well-grown system starts to feel like one you should rewrite from scratch, which is precisely the from-scratch trap Gall's law warned you away from. The rot is the same knowledge decay that hollows out every other kind of working knowledge, arriving at the worst possible layer of your architecture.

This is the problem Scribelet is built for. Its background agents re-check your notes and decision records against reality on a schedule and surface a diff when something no longer holds, so the reason a layer of complexity exists stays attached to the layer instead of evaporating by the time someone proposes tearing it out. Your keys, your model, your data: the agents run on the provider you choose, and you see exactly what changed and why. Capturing the why behind each evolutionary step, the way you would an architecture decision record, is what keeps a grown system legible enough to keep growing, instead of becoming the tangled thing that tempts the next team into a doomed clean-slate rebuild. A system whose reasons have silently gone out of date is one you will feel forced to redesign from scratch, because you can no longer separate the complexity that earns its place from the complexity that is just old. And a system that keeps piling on features whose original justification nobody can name is already sliding into feature creep, the accretion end state of an evolution that stopped recording its reasons.

Getting started

Gall's law is not advice to build small and stay there. It is advice about direction of travel: reach the complex system you want by growing it from a simple one that genuinely works, because the from-scratch route validates its riskiest assumptions only at the end, when being wrong is most expensive. The grand whiteboard design fails not because the team lacked skill but because it tried to specify interactions that do not exist until the parts are running.

Do three things with it. Make your first version a system that actually does its core job end to end, not a fragment that only looks like it does, so you have a real seed to evolve. Add complexity one justified layer at a time, and resist the pull to design the whole thing up front or to make the next rewrite a grand one. And record why each layer was added, because the reasons decay faster than the code and their loss is what turns healthy evolution into blind accretion. Try Scribelet free and let it keep the reasoning behind your system current, so the complex thing you grow stays one you can still understand.