Gall's Law

On October 1, 2013, the United States launched Healthcare.gov, the centerpiece of the Affordable Care Act's health insurance marketplace. The system was designed to serve millions of Americans across all fifty states, integrating databases from the IRS, the Social Security Administration, the Department of Homeland Security, and hundreds of insurance companies into a single, comprehensive platform. The specifications ran to thousands of pages. The development involved fifty-five contractors coordinated by the Centers for Medicare and Medicaid Services. On launch day, of the estimated 250,000 people who attempted to register, only six completed enrollment. The site crashed repeatedly, returned error messages, lost applications, and failed at nearly every integration point. Over the following months, the administration brought in a rescue team that stabilized the system through incremental fixes -- patching one component at a time, testing against real user behavior, and growing functionality piece by piece. The system that eventually worked was not the system that was designed. It was the system that evolved.

Gall's Law states: "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 with a working simple system." John Gall articulated this in his 1975 book Systemantics: How Systems Really Work and How They Fail. This is NOT the same as the general advice to "start small" or "keep it simple." Gall's Law makes a specific empirical claim about the relationship between complexity and function: working complexity is always the product of evolutionary accretion from working simplicity. It cannot be conjured into existence through design, no matter how intelligent the designers.

Why Designed Complexity Fails

The mechanism behind Gall's Law is rooted in the nature of complex system interactions and the limits of human prediction. Stuart Kauffman, the complexity theorist at the Santa Fe Institute, formalized a version of this insight in his work on "rugged fitness landscapes." In any complex system, the components interact in ways that create a vast space of possible states. Small changes to one component can cascade unpredictably through others. Kauffman demonstrated mathematically that as the number of interacting components grows, the number of possible interaction effects grows combinatorially -- far faster than any designer can anticipate. A system with ten interacting components has on the order of 1,024 possible interaction states. A system with fifty components has over a quadrillion. No design document, no matter how detailed, can enumerate these interactions in advance.

This is why a working simple system is the necessary starting point. A simple system has few enough interactions that its behavior can be observed, understood, and corrected. When you add one component to a working simple system, you introduce a manageable number of new interactions. You discover which ones cause problems, fix them, and stabilize the system before adding the next component. Each increment inherits the tested stability of everything that came before it. The evolutionary path from simple to complex is a path through a series of working states, each one validated against reality. The designed path from nothing to complex skips all of those intermediate validations and arrives at a state whose interactions have never been tested. Healthcare.gov attempted the second path and got the predicted result.

Two Scales of Evidence

At the systemic scale, the history of the internet is the most compelling positive example of Gall's Law in action. ARPANET, the internet's precursor, connected exactly four computers in 1969: UCLA, Stanford Research Institute, UC Santa Barbara, and the University of Utah. The protocol was simple -- packet switching between a handful of nodes. That worked. The network grew to connect dozens of research universities. That worked. TCP/IP replaced the original protocol in 1983, but it was layered onto a network whose basic functioning had been proven at smaller scale. The World Wide Web was added in 1991 as a layer on top of an already-working internet. E-commerce was layered on top of a working web. Cloud computing was layered on a working commercial internet. Each layer of complexity was added to something that already functioned, tested against real users, and stabilized before the next was applied. Nobody designed the internet as a global system for four billion users. It evolved into one.

Contrast this with France Telecom's Minitel, which attempted in the 1980s to design a comprehensive national information system from scratch. While initially successful within its constrained French context, its centralized architecture -- designed comprehensively rather than evolved incrementally -- proved unable to adapt when the decentralized, evolved internet emerged. Minitel could not accommodate the explosive, unpredictable growth patterns that the internet's evolutionary architecture handled naturally, and it was eventually shut down in 2012.

At the personal scale, consider anyone who has tried to overhaul their entire life at once -- a new exercise routine, a new diet, a new sleep schedule, a new productivity system, all starting Monday. Research by Phillippa Lally and colleagues at University College London, published in the European Journal of Social Psychology in 2010, found that forming a single new habit takes on average sixty-six days. Attempting to form multiple habits simultaneously undermines all of them, because each habit competes for the limited willpower and attention that the others also require. The person who succeeds at lasting behavioral change almost always does so incrementally: master one habit, stabilize it, then add the next. The "complete life overhaul" is the personal equivalent of designing a complex system from scratch, and it fails for exactly the same reason -- the interactions between the components are too numerous to manage simultaneously.

The Graveyard of Grand Designs

History offers abundant negative evidence for Gall's Law.

Joel Spolsky, co-founder of Stack Overflow, wrote in 2000 that the "complete rewrite" is the single worst strategic mistake a software company can make. His case study was Netscape, which decided in 1998 to rewrite its browser from scratch rather than incrementally improve the existing codebase. The rewrite took three years. During those three years, Internet Explorer -- which was being incrementally improved -- captured the browser market. When Netscape finally shipped the rewritten browser, it was too late. The old codebase, for all its messiness, had contained years of accumulated fixes for real-world edge cases -- bugs that users had reported, compatibility issues that had been patched, performance optimizations for specific hardware. The rewrite threw all of that evolved knowledge away and had to rediscover it from scratch.

The centrally planned economies of the 20th century are the largest-scale example of designed-from-scratch systems failing. Soviet economic planning attempted to design an entire economy comprehensively -- determining what to produce, in what quantities, at what prices, and for whom. The plans were detailed, rational, and produced by intelligent people with access to extensive data. They consistently failed to match the performance of market economies, which are not designed at all but evolve through billions of independent transactions. The market's advantage is not superior intelligence. It is evolutionary adaptation -- continuous, distributed testing of small changes against reality, with failures eliminated and successes propagated.

Limitations and Failure Modes

Gall's Law is a powerful heuristic, but it has failure modes that must be acknowledged.

First, the law can be used to justify excessive incrementalism -- an unwillingness to make bold changes or ambitious plans. Some situations genuinely require discontinuous leaps. When the Space Shuttle program was conceived, NASA could not incrementally evolve from the Apollo capsule to a reusable spacecraft through small variations. Certain design constraints require architectural breaks. Gall's Law suggests these breaks should be minimized and that each new architecture should be validated at small scale before being extended, but it does not prohibit bold design entirely.

Second, the law does not distinguish between different kinds of complexity. Complexity that arises from necessary domain requirements (a healthcare system genuinely needs to integrate with multiple federal databases) is different from complexity that arises from poor design choices. Gall's Law applies most forcefully to the first type: you cannot anticipate all the interactions inherent in necessary complexity. But some complexity is unnecessary and can be eliminated through better design rather than evolutionary accretion.

Third, "start with a simple system that works" can be interpreted too literally. The simple system needs to be a legitimate foundation for the eventual complex system, not just any simple system. A working bicycle is a simple system, but it is not an evolutionary precursor to an airplane. The simple starting point must share the fundamental architecture of the intended complex system.

Fourth, evolutionary accretion can produce systems that work but are deeply suboptimal -- carrying the accumulated weight of every historical adaptation, many of which are no longer necessary. The human body is an evolved complex system that works, but it also carries an appendix, a spine not well-suited for upright walking, and a birth canal constrained by pelvic dimensions that made sense for quadrupeds. Evolution produces function, not elegance.

Fifth, Gall's Law offers no guidance on how fast to evolve. Adding components too slowly wastes time. Adding them too quickly overwhelms the system's capacity to stabilize. The optimal pace of evolution is itself a complex question that the law does not answer.

Cross-References

First principles thinking and Gall's Law exist in productive tension. First principles thinking helps you understand the fundamental constraints of your domain -- what must be true for any solution to work. Gall's Law reminds you that understanding constraints is not the same as predicting system behavior within those constraints. You need first principles to identify what to build. You need evolutionary iteration to discover how it behaves.

Technical debt connects because one of the most common and dangerous forms of technical debt is the "grand rewrite" -- the attempt to eliminate all accumulated debt by building a replacement system from scratch. Gall's Law predicts that such rewrites will fail, because the existing system, however debt-laden, contains evolutionary knowledge about edge cases and real-world behavior that the new system must rediscover. The alternative -- incremental refactoring that pays down debt while preserving working functionality -- is the Gall's Law-compliant approach to debt management.

Second-order thinking is essential when applying Gall's Law because the law is fundamentally about unintended consequences -- the interactions and cascading effects that designed systems cannot anticipate. Each component added to a system produces not just its intended function but second- and third-order effects on everything it interacts with. Evolutionary development discovers these effects incrementally. Comprehensive design encounters them all at once.

Epistemic humility is the philosophical foundation of Gall's Law. The law is essentially a statement about the limits of human knowledge: we cannot know enough about complex system interactions to design them from scratch. Accepting this limitation -- and designing processes that accommodate it rather than deny it -- is the practical application of epistemic humility to system design.

The Self-Test: The Complexity Origin Trace

Here is a named test for evaluating whether a proposed system is likely to work. For any complex system you encounter -- or are asked to build -- trace its origin. Did it evolve from a simpler system that worked at smaller scale? Or was it designed comprehensively and launched at full complexity? If the former, it has a foundation of evolutionary validation. If the latter, Gall's Law predicts it will fail.

The internal experience of applying this test is often one of deflation. Grand designs are exciting. Comprehensive solutions feel intellectually satisfying. The evolutionary alternative -- start with something embarrassingly simple, ship it, learn what breaks, fix it, add one thing, repeat -- feels unglamorous and slow. The test requires accepting that the unglamorous path is more likely to produce a working system than the exciting one.

The trigger situation is any time someone proposes building a comprehensive solution to a complex problem -- a complete organizational restructuring, a total platform migration, an all-encompassing policy reform, a complete life overhaul. When the proposal skips the working simple system and goes directly to the working complex system, Gall's Law is the voice saying: this path has been tried before, and it has a failure rate that should make you uncomfortable.

The System That Evolved

Return to Healthcare.gov. The comprehensive system that launched on October 1, 2013, did not work. The system that eventually served millions of Americans was not the designed system patched up. It was, in effect, a different system -- rebuilt incrementally by a team that started with the most basic functionality (can a user create an account?), got that working, then moved to the next function (can we verify identity?), got that working, and progressed outward, testing each addition against real users before layering on the next. The rescue team did not have less ambition than the original designers. They had the same goal. But they had internalized, whether consciously or through hard experience, the principle that John Gall articulated four decades earlier: you cannot design your way to a working complex system. You can only evolve your way there, one working increment at a time.