Laws & Disorder #4 — Gall's Law: Great Systems Are Built From Small Bricks, Not Big Plans
written by Stefan Christoph
Fourth in “Laws & Disorder.” After Conway’s Law, Hyrum’s Law, and Tesler’s Law, here’s the one that quietly governs every migration and every rewrite.
The most expensive projects I have watched go sideways share a shape. Someone drew the full, glorious end-state on a whiteboard: event-driven, multi-region, every service in its final form, and then set out to build all of it at once. It rarely arrived. Not because the people were weak, but because you cannot foresee how that many moving parts will interact until some of them are actually running.
That is Gall’s Law, and it is the most reliable predictor of a doomed architecture I know.
The law
John Gall, in his 1975 book “Systemantics” (later “The Systems Bible”), put it this way [1]:
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, beginning with a working simple system.
Thirty publishers passed on the book. The law outlived all of them.
Two readings, both true
There are two ways to read Gall’s Law, and I want both on the table because they reinforce each other.
The temporal reading is the one most people know: start with a simple system that works, then evolve it. This is the theoretical backbone of the MVP and of Martin Fowler’s “monolith first” advice, that you should begin with a monolith and extract services only once real usage teaches you where the seams belong [2].
The compositional reading is the one I lean on, and it is about structure rather than time: you build a complex system by composing small, well-defined, low-complexity parts. The richness of the whole emerges from the simplicity of the pieces. You did not design the complexity. You assembled it from bricks that each work.
Unix: the proof of the compositional reading
The cleanest example is Unix. A small kernel and a large collection of tiny tools, each with a tight, well-defined scope, each very good at exactly one job: find finds, grep matches, sort sorts, uniq deduplicates. On their own they are almost trivial. Chained together with pipes, find | grep | sort | uniq, they produce behavior rich enough to run the world’s infrastructure for fifty years. The Unix philosophy, “do one thing well, and compose,” is Gall’s Law expressed as a design discipline [3]. Nobody sat down and designed the full space of everything you can do at a Unix shell. It emerged from small parts that each worked.
Compose small parts into rich behavior. Design the whole complex thing up front and it cracks.
AWS: primitives as building blocks
The cloud version is the same idea. The core AWS services are small, well-scoped building blocks: object storage, a function runtime, a queue, a key-value store. On their own each is simple to reason about. You assemble them into something complex the way you assemble Lego bricks into a house or a car. And crucially, if you tried to build the complex end-state without those foundational primitives, from scratch, you would hit the same wall Gall described.
“Building blocks” is the right synonym for the whole idea, and it is a strength, not a limitation. Small, composable primitives are what let you start with something that works and grow it, instead of betting everything on a design you cannot yet test.
This is exactly why the sanest cloud migrations start ugly. You do not redesign everything in flight. You get the working system running first, often by rehosting it largely as-is, and then you modernize incrementally, peeling off one capability at a time using the strangler-fig pattern, wrapping the old system and gradually replacing pieces of it with composed primitives [4]. AWS’s own migration guidance formalizes this range of moves as the 7 Rs, from Rehost and Replatform through Refactor, precisely so you can sequence the change instead of attempting it all at once [5]. Start with the simple system that works. Compose the complex one from bricks. Never big-bang it.
To be clear, none of this is anti-ambition, and none of it means “monolith forever.” Microservices and event-driven architectures are excellent as an evolved, composed state. The failure is trying to arrive there in a single leap. Compose and sequence; don’t lower the ceiling.
The AI twist: build the bricks, don’t skip them
Now the forward-looking part, marked as my reading as of 2026.
AI makes it feel cheap to violate Gall’s Law faster than ever. You can prompt an assistant and watch a whole complex system get scaffolded in an afternoon: services, wiring, infrastructure, all of it, in one shot. It is genuinely impressive, and it is exactly the temptation Gall warned about, now available on demand. A complex system generated from scratch is still a complex system designed from scratch. The fact that a machine typed it does not mean anyone validated how the parts interact.
The building-block counter is the constructive move. Use AI to build good, small, well-scoped bricks, the focused components that each do one thing well, and to help you compose and evolve them. That plays to what Gall’s Law says actually works: simple parts, validated, assembled into richness. Point the same tool at “generate the whole complex blob” and you have just automated the failure mode. Same technology, opposite discipline.
If you’re running this on AWS
- Migrate in stages. Rehost the working system first, then modernize with strangler-fig, peeling off one service at a time [4], [5]. Resist the in-flight redesign.
- Compose from primitives. Reach for small, well-scoped services and snap them together, rather than a single monolithic platform choice you can’t evolve.
- Make each brick work before the next. Every increment should run end to end and be tested against reality before you add the next one. That is the whole safety mechanism.
- Aim AI at bricks. Use it to build and refine focused components, not to one-shot an unvalidated complex system.
A complex system that works was assembled from simple parts that worked. That is not a constraint on your ambition. It is the only known route to the ambitious thing actually running.
What are you currently trying to build in one shot that would be safer to compose from bricks?
More in this series
Follows Tesler’s Law (small well-scoped parts carry less inherent complexity) and connects back to Conway’s Law. Next comes Goodhart’s Law. Sparked by the Laws of Software Engineering collection [6].
Sources
- [1] Systemantics / The Systems Bible — Wikipedia — John Gall’s 1975 book and the statement of the law.
- [2] Martin Fowler — MonolithFirst — the temporal reading: start with a monolith, extract services as you learn.
- [3] Basics of the Unix Philosophy — Eric S. Raymond — do one thing well and compose.
- [4] Martin Fowler — StranglerFigApplication — incrementally replace a system by wrapping and peeling.
- [5] AWS — Migration strategies: the 7 Rs — Retire, Retain, Rehost, Relocate, Repurchase, Replatform, Refactor.
- [6] Laws of Software Engineering — Gall’s Law — the collection that sparked this series.
About the Author
Stefan Christoph is a Principal Solutions Architect at AWS, focused on agentic AI, media & entertainment, and helping builders move from demo to production. He writes about AI architecture, developer productivity, and the future of software.
This is a personal blog. Opinions expressed here are my own and do not represent the views or positions of my employer.
❤️ Created with the support of AI (Kiro)