Pattern/Aphorism/No. 0412
Gall’s Law
Gall’s Law is a systems design aphorism stating that successful complex systems grow from simpler ones that already work. Described by John Gall in Systemantics (1975), it favors gradual expansion over design from scratch, but is not a proven universal law or a guarantee of success.
- Evidence
- Useful, modest evidence
- Read
- 6 min
- Links
- 8 connections
01You've seen this when…
- at work
The new operations platform has diagrams for purchasing, stock control, billing, and returns. Six months into development, it still cannot deliver one customer order.
- in life
You spend Saturday configuring a complete productivity system: tags, dashboards, recurring tasks, and weekly reviews. On Monday, you cannot find the appointment you need.
- out in the world
A city plans to replace every department’s booking software with one shared platform. The launch date approaches, but no library has successfully booked a room through it.
02The idea
A complete design can look convincing before any part of it meets reality. Every box has a purpose. Every arrow connects. What the diagram cannot show is whether the whole arrangement will actually work.
Gall’s Law favors a different route: make a simpler system work, then expand it while preserving what works. Each addition has something real to connect to and something real to be tested against.
Gall stated the pattern much more strongly: successful complex systems grow from working simple ones, while complex systems designed from scratch fail. Treat that absolute wording as a provocation. The universal claim remains unproven.
Simple means limited in scope, not missing essential safeguards. A booking service for one library can be simple and complete. A citywide booking service without reliable cancellation or access controls is unfinished.
This is related to a minimum viable product, with a different focus. An MVP is a way to test assumptions about a product. Gall’s Law is a caution about how working systems acquire complexity. It applies to software and to the processes used to run businesses or public services.
03Why it happens
- Interactions are harder to predict than parts. Purchasing can work alone, and billing can work alone, yet connecting them can expose incompatible definitions of an order. Adding components also adds relationships, exceptions, and coordination needs. Modularity helps contain this problem, but does not eliminate it.
- Use exposes assumptions that planning misses. Real users submit incomplete information, change their minds, and invent workarounds. A functioning small system brings work as imagined closer to work as done before those assumptions spread through the entire design.
- A working baseline makes failures easier to locate. If yesterday’s process worked and today’s addition breaks it, you have a useful starting point for diagnosis. If nothing has ever worked end to end, nearly every component and connection remains suspect.
- Smaller changes shorten the learning cycle. Teams can see consequences, correct mistakes, and try again. Those feedback loops become much weaker when the first useful result arrives only after years of construction.
None of this guarantees success. A small system can work because one expert quietly rescues it every afternoon. Expanding that arrangement may expand its hidden dependence rather than its capability.
04A worked example
The early World Wide Web provides a historical illustration. In 1989, Tim Berners-Lee proposed it at CERN to help people share information. His browser and web server were working there by the end of 1990. That initial implementation used an already functioning Internet and was far narrower than today’s Web.
What it looks like A vast global information system emerging from a design for connecting documents.
What’s actually going on The first implementation could do a small but complete job: serve pages and let someone follow links between them. That was enough to make it useful while shopping online and using the Web to stream video or participate in social networks remained beyond its scope. Other servers and browsers followed, and people found new uses for the Web. CERN’s release of the Web software into the public domain in 1993 also allowed others to build on it.
What would have helped For a team attempting comparable growth, the transferable move is to get one real exchange working over dependable infrastructure, then test additions against it. Do not make every imaginable future use a requirement for the first release.
This case illustrates Gall’s preferred route while leaving its universal claim unproven. The Web also required substantial invention and deliberate choices about protocols. Starting small still required design.
05How to spot it
06What to do about it
- Choose one complete, useful path. Deliver one order, process one application, or book one room. Include the essential checks and a way to recover from mistakes. A working simple system connects its components into a complete, usable path.
- Define working in observable terms. Name who uses it, what they accomplish, and what acceptable reliability means. Count manual rescue work rather than hiding it behind a successful demonstration.
- Reuse dependable foundations. Existing payment services, established procedures, and proven infrastructure can reduce the number of things you must invent simultaneously. Check that they actually fit your needs.
- Introduce uncertainty in bounded steps. Try a safe-to-fail experiment with one location or a limited group where appropriate. Keep a fallback, and decide what evidence would justify expanding. Safety-critical work needs stricter testing than a casual pilot.
- Leave room for replacement. Use clear boundaries between parts, and document shortcuts. Otherwise today’s successful prototype can become tomorrow’s technical debt.
- Expand from observed needs. Let actual bottlenecks and failures guide the next addition. The point of build-measure-learn is to let learning from use guide what you ship next.
07Where it doesn’t replace engineering
Some systems cannot deliver a useful service until many tightly connected parts are ready. A bridge needs more than one working pier. A reactor cannot acquire its safety systems after it begins operating. Such projects still benefit from proven components, staged testing, and careful commissioning, but Gall’s aphorism is not a complete construction method.
Success at a small scale leaves large-scale performance uncertain. One employee can coordinate ten customers personally. Ten thousand customers may require a different structure to handle the larger scale.
Growing from what works also creates path dependence: early decisions shape what becomes easy or expensive later. Sometimes replacement is better than another extension. Stay willing to replace an obsolete system when applying Gall’s Law.
The practical distinction is between planning ahead and assuming the plan has already been validated. Think about scale, interfaces, security, and failure early. Then seek evidence that the design works. A complete design on paper still awaits that evidence.
08Roots
In 1975, pediatrician John Gall published Systemantics. Even the title teased its subject: systems theory with a suggestion of antics. Gall examined institutional behavior by collecting pointed observations about how systems malfunction, pursue their own purposes, and frustrate the people they are supposed to serve.
The working-simple-system principle belonged to that larger argument. Gall drew on examples from organizations and engineered systems, giving his argument an observational basis. A controlled study comparing development methods lay outside that evidence base. His target was confidence in elaborate arrangements whose designers understood their intentions better than their behavior. A system doing a job in practice supplied evidence about behavior. A grand design supplied a plan awaiting that evidence.
The observation later became known as Gall’s Law. Gall expanded his work in later editions, eventually titled The Systems Bible. The aphorism found a receptive audience among software developers and designers dealing with large projects that looked coherent until their parts met. Its endurance owes more to that recognizable experience than to the literal truth of its strongest wording.
09How solid is this?
A design aphorism supported by plausible mechanisms and historical examples, not an established universal law. Working predecessors can reduce uncertainty, but they neither guarantee success at scale nor establish that complex designs from scratch must fail.
10Connections
- Helps counter Technical Debt
- Includes Minimum Viable Product
- See also Feedback Loops, Path Dependence, Work-as-Imagined vs. Work-as-Done, Safe-to-Fail Experiment, Build-Measure-Learn, Modularity
11Origin and sources
John Gall described the principle in Systemantics (1975). The aphorism later became known as Gall’s Law.
- [1]Gall, J. (2002). The Systems Bible: The Beginner's Guide to Systems Large and Small. General Systemantics Press.
- [2]Berners-Lee, T. (1989). Information Management: A Proposal. CERN.
- [3]CERN. The birth of the Web.
Suggest an edit· Updated 2026-10-02