Complex systems that work evolved from simple systems that worked.
John Gall's 1975 observation, from Systemantics: you can't design a complex system from scratch and have it work. The complex ones are descendants of simple ones that were shipped and used. Skip the simple ancestor and the descendant never breathes.
Big systems are grown, not designed. Start with the smallest thing that works end-to-end, ship it, learn from it, then grow it. The grand design built from scratch — the one no simple version ever shipped — rarely survives contact with the real world.
The first version should do the smallest possible thing end-to-end. Sign in, post one thing, see it. The walking skeleton proves the path exists; the muscles get built on top of a working spine.
The classic Gall violation. Two years on a "from scratch" replacement, no working version in sight, deadline keeps slipping. By the time it ships, the requirements have changed and the people who knew them have left. The system never finds the version where it actually worked.
HTTP started as one page-fetching protocol. The web today — apps, video, payments, AI — is the same protocol with thirty years of layers welded on. Every working complex system reads like that: TCP, Linux, the iPhone OS, Notion, your codebase. None of them were built right; they were built first.
Lean, Agile, Eric Ries — all of them are Gall in different vocabulary. Ship the smallest thing that proves the idea, learn from real users, iterate. The MVP isn't a marketing concept; it's the only way most working complex systems come into existence.
Material, HIG, your own design system — none of them were specced from the top. They started as a button, a font scale, a color. They grew because the simple version was used. The "let's design the whole system first" approach has produced a graveyard of unused tokens and dead components.
Gall's other warning: a system that worked at a small scale won't necessarily work at a larger one — and you discover the breaks only by growing into them. Don't extrapolate; observe. The simple version proves this case worked, not every future case.
Gall isn't universal. Bridges, planes, payment systems, surgery robots — anything where iterating in production is catastrophic — need formal specs up front. The rule applies where iteration is cheap and recoverable, which is most of software, most of the time.
When a teammate proposes the perfect architecture three quarters out, the Gall response is: what's the smallest version of this we can ship next sprint? Force the working ancestor. The grand plan can survive that question; if it can't, it wasn't grand, it was just big.
AI lets you generate a "complete" system in a day — and then ship something that has no working ancestor to grow from.
"Build me an entire app" produces output that looks like a system. But it has no ancestor — no simple version that anyone ran in anger, no scars from real use. The code may compile, but the design hasn't earned the right to be complex. Use AI to ship a simple thing fast, not a complex thing untested.
The upside is real. AI shortens the cycle between "working version 1" and "working version 2" — code, copy, design, all generated faster. Gall's law isn't repealed; it's accelerated. You still need a working ancestor at every step. You just get to make many more of them.