What is Gall's law?
Engineering culture and software practice
Gall's law holds 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 into working, so you must start over with a working simple system. John Gall stated it satirically in his 1975 book Systemantics. Software and startup culture adopted it as a serious argument for building simple things first and letting them grow.
What this means
Gall's law is a rule of thumb about how working complexity actually comes into being. Its claim is that the big, intricate systems we admire did not arrive fully formed; they grew, step by step, from small systems that already worked. And its harder half is that trying to design a complex system whole, from a blank page, tends to produce something that does not work and cannot be rescued by patching.
The reason it resonates is that we usually only see the finished, complex system and forget the long evolution behind it. That blindness tempts people to build the complex thing directly, which is exactly what the law warns against.
Applied seriously, it becomes a design discipline: start with the simplest version that genuinely works, confirm it works, then add complexity a piece at a time, keeping the whole working at each step. It is the same lesson as the rewrite trap, seen from the other direction.
Why it matters
For any organisation embarking on a big technology change, Gall's law is a warning against the grand build. The instinct in a boardroom is often to design the complete, ideal system up front and deliver it in one ambitious programme. The law predicts that this is precisely how you end up with something that never quite works, because the interactions and edge cases you could not foresee only reveal themselves once real use begins.
It matters for the recurring pain of large enterprise programmes. Big-bang ERP and CRM rollouts, delivered all at once, are notorious for overrunning and underdelivering, and Gall's law names the underlying reason: complexity that has not been grown from a working base tends to fail in unexpected ways. Starting with a simple working slice and expanding it is not timidity; it is the route that actually reaches working complexity.
It matters especially for AI programmes, which are often conceived as grand platforms before any single useful workflow exists. A leader who takes Gall's law seriously will resist the urge to build the cathedral first, and will instead grow capability from something small that demonstrably works, learning as it expands.
How it works
Where the term came from
John Gall was an American paediatrician, not a software engineer, and his 1975 book Systemantics was satire about why systems, especially bureaucracies, behave and fail as they do. It was expanded in 1977 and 1986 and retitled The Systems Bible in its third edition of 2002, published by the General Systemantics Press. Among its many capitalised axioms is the one that became known as Gall's law: a complex system that works is invariably found to have evolved from a simple system that worked, and a complex system designed from scratch never works and cannot be patched up to make it work; you have to start over with a working simple system.
The register matters. Gall was writing with deliberate exaggeration, and words like "invariably" and "never" are part of the joke as much as the claim. The software world then adopted the line as a genuine design principle, which is fair enough as long as one remembers it began as witty overstatement rather than a measured empirical law. The same instinct appears in serious engineering writing: Fred Brooks recommended in No Silver Bullet that software be grown incrementally rather than built whole, and the scholarly root goes back at least to Victor Basili and Albert Turner's "Iterative Enhancement" in IEEE Transactions on Software Engineering in 1975, which recommended starting with a simple, skeletal implementation and enhancing it in successive steps. Eric Ries's The Lean Startup (Crown, 2011) carried the same instinct into business as the minimum viable product and validated learning.
The mechanism: feedback, learning and undiscovered assumptions
The engine behind Gall's law is feedback. A simple working system meets reality immediately, so its hidden assumptions are tested and corrected while they are still cheap to fix. A complex system built whole hides all its assumptions inside one large design, and they are only tested at the end, when they are expensive and entangled. Growing a system means each added piece is validated against real use before the next is added, so errors are caught small. Building it whole means the first honest test comes late, when a single wrong assumption can bring down the lot.
How software and startup culture adopted it
The principle underpins much of modern practice. The advice to start with a monolith and split off services only once you understand them, the minimum viable product, the walking skeleton (a tiny end-to-end version that does something real before features are added), and iterative delivery all express Gall's law. Startups adopted it because building the fully featured product before knowing what customers want is the classic way to fail; growing from a small thing that works lets the product find its shape.
How experienced teams apply it, and where they do not
Experienced teams use the law to structure delivery: define the simplest version that provides real value, ship it, confirm it works in genuine use, then enhance. Crucially, they insist the simple system actually works before adding to it, because the less-appreciated half of the law is that the base must be functional, not merely small. They also know the limits. Growing a system is not the same as letting it accrete without design into a tangled mess, and some domains cannot be grown casually at all.
Examples
A charity wants a supporter system that does everything: donations, events, volunteering, communications and reporting, all integrated from day one. Warned by Gall's law, the trustees instead commission a simple donation-and-contact system, get it genuinely working for the fundraising team, and only then add events and volunteering module by module. Each addition is tested against real use, and the charity ends up with a working complex system rather than a stalled grand build.
A retailer plans a single large programme to replace its ageing stock, pricing and ordering software all at once. Remembering how big-bang rollouts fail, the operations director reframes it as a sequence: first a simple working stock module used in one region, confirmed in practice, then pricing, then ordering, then wider rollout. Progress is visible throughout, and problems surface while they are still small and local.
A professional services firm is tempted to build a grand AI platform spanning every department before anything is live. Applying Gall's law, it instead picks one narrow workflow, say drafting first versions of standard letters, and gets that working reliably for one team. Only once it demonstrably works does the firm extend the approach to neighbouring tasks, growing the capability from a working core rather than designing the whole platform in the abstract.
Common misunderstandings
A frequent misreading is that Gall's law forbids any up-front design or planning. It does not. It argues against building the whole complex system in one go with no working intermediate stages; having a target architecture in mind is fine, as long as you have a path from a simple working version to it.
Another is taking "invariably" and "never" as literal, tested absolutes. Gall was writing satire, and the words are partly rhetorical. The serious content is a strong tendency, not a proven certainty that no complex system was ever successfully designed whole.
A third confusion is with the second-system effect. The second-system effect is about the specific danger that the over-ambitious successor to a modest first system becomes bloated. Gall's law is broader: rather than warning only about second systems, it is a general principle that working complexity evolves from working simplicity, and it applies to processes and organisations as much as to code. YAGNI, the advice not to build speculative features, is a close cousin but narrower, being about features rather than about how whole systems come to work.
A fourth error is thinking that "start simple" means "let it sprawl". Uncontrolled accretion produces a big ball of mud, which is a failure, not a fulfilment, of the law. Evolving deliberately is different from accreting carelessly.
A fifth is assuming the law means the simple version can be rough. The overlooked requirement is that the simple system must actually work before you build on it; a simple thing that does not work is not a foundation.
Risks and boundaries
The law has real limits that its satirical confidence hides. Safety-critical and heavily regulated systems, such as aircraft control or medical devices, genuinely do need substantial up-front design and cannot simply be evolved from a rough working version in production. In those domains the cost of learning by failing in the field is unacceptable, and the law must be tempered by rigorous specification.
There is also the accretion risk. "Grow it" can become an excuse for never designing anything, so the system evolves into an unmaintainable tangle. Evolution without architectural care produces the big ball of mud, which is precisely what good teams are trying to avoid. The law is not a licence to skip design; it is an argument about sequencing.
And because it began as satire, it should not be wielded as an iron law in disputes. It is a strong, useful heuristic with a long pedigree in serious engineering, but "Gall said never" is not an argument. The honest framing is that incremental evolution from a working base is usually the safer route to working complexity, with clear exceptions where up-front design is essential.
What to do next
When a programme is proposed as a single grand build, ask what the simplest version that delivers real value looks like, and insist on delivering and proving that first. Treat the big design as a direction of travel, not a thing to construct all at once.
Sequence large changes such as ERP, CRM or AI platforms into stages that each work in genuine use before the next begins. Visible working progress at each step is both safer and easier to fund than a distant all-or-nothing delivery.
Hold the line that the simple version must actually work, not merely exist. A pilot that never quite functions is not a foundation to build on, so judge each stage by whether it does its real job before extending it.
For AI, start with one narrow workflow that clearly helps one team, confirm it works, and grow from there. Resist building the enterprise-wide platform before a single workflow has earned its place.
Know your exceptions. Where systems are safety-critical or regulated, budget for proper up-front design and specification, and do not use Gall's law to justify skipping it. Match the amount of up-front design to the cost of failing in the field.
FAQs
Who was John Gall and where does the law come from?
John Gall was an American paediatrician who wrote Systemantics in 1975, a satirical book about how systems work and fail. One of its axioms became known as Gall's law. The book was later expanded and retitled The Systems Bible in 2002.
What does Gall's law actually state?
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 into working, so you must start over with a working simple system.
Should I take "invariably" and "never" literally?
Not entirely. Gall was writing satirically, and the absolute words are partly rhetorical. The serious message is a strong tendency: growing complexity from a working simple base is usually far more reliable than building it whole.
How does it relate to the minimum viable product?
The minimum viable product is Gall's law applied to business. Eric Ries's The Lean Startup argues for building a simple version, learning from real use, and growing it, rather than building the full product before knowing what works.
Is Gall's law the same as the second-system effect?
No. The second-system effect is the narrower danger of an over-ambitious successor to a first system. Gall's law is a broader principle that working complexity evolves from working simplicity, applying to organisations and processes too.
Does it mean I should never plan a system in advance?
No. It warns against building the whole complex system in one go. You can and should have a target design, provided you have a route from a simple working version to it.
When does the law not apply well?
In safety-critical or regulated domains, such as medical devices or aircraft systems, where failing in real use is unacceptable and substantial up-front design is essential. There the law must be tempered by rigorous specification.