Laws & Disorder #4 — Gall's Law: Great Systems Are Built From Small Bricks, Not Big Plans

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, a heuristic, not a theorem, but 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. The MVP and Martin Fowler’s “monolith first” advice run on the same intuition, compatible heuristics, not documented derivations from Gall: 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 my extension rather than what Gall wrote, a companion design principle 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. Simple here means the part itself, its code, its state, its interface, stays small enough to hold in your head; the interactions between parts are where complexity re-enters, which is why the seams deserve the most care.

Unix: the compositional reading in practice

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 far richer than any of the parts, a pattern that has stayed load-bearing across five decades of Unix-family systems. 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.

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 presents a bounded interface you can reason about, simple at the seam, though the configuration, quotas, and failure modes behind it remain real work. 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 catalogs this range of moves as the 7 Rs, from Rehost and Replatform through Refactor, a menu of per-workload strategies rather than a prescribed sequence, but exactly the vocabulary that lets you stage 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 can be excellent as an evolved, composed state, when the scale, the team structure, and the operational appetite call for them. 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,” skip validating the parts, and you have just automated the failure mode. Same technology, opposite discipline.

If you’re running this on AWS

• Migrate in stages. Get the working system running first, rehosting is often the cheapest way there, though some workloads warrant replatforming or replacement, 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 most dependable route I know 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] John Gall, Systemantics: How Systems Really Work and How They Fail (1st ed., Pocket Books, 1978), the law appears among the elementary systems functions (pp. 79–82, per the footnotes of the Wikipedia article, which also documents the publication history and the thirty-rejections story).
• [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.

Learn more →

• LawsAndDisorder
• Architecture
• AWSArchitecture
• Migration
• AIAgents