Skip to main content
Category: Laws
Type: System Design Law
Origin: Systems Theory, 1975, John Gall
Also known as: Gall’s Law, Complex System Evolution
Quick Answer — Galls’ Law is a principle stating that every complex system that works has evolved from a simple system that worked. The law, formulated by John Gall in 1975, suggests that complex systems are ultimately fragile and tend to fail, while simple systems that have been proven to work provide a more reliable foundation for development.

​
What is Galls’ Law?

Galls’ Law proposes that complex, fully-functional systems cannot be designed or developed from scratch—they must evolve from simpler, working systems. The core insight is that a complex system that succeeds has done so not through comprehensive planning but through iterative development, where each stage built upon a foundation that already worked.
“A complex system that works is invariably found to have evolved from a simple system that worked.”
This principle challenges the approach of trying to design perfect systems upfront. Instead, it suggests that the path to complex, effective systems runs through proven simplicity. Each successful complex system is the descendant of simpler ancestors that already solved core problems.

​
Galls’ Law in 3 Depths

  • Beginner: When building something new, start with the simplest possible version that solves the core problem. Don’t try to build the complete solution immediately—prove the basic concept works first.
  • Practitioner: When evaluating proposed solutions, assess whether they evolved from working simpler versions. Complex systems that were “designed” from scratch rather than evolved often fail in unexpected ways.
  • Advanced: Understand that evolution requires selection pressure. Simple systems become complex systems through iteration under real-world conditions—not through hypothetical planning.

​
Origin

Galls’ Law is attributed to John Gall, a systems theorist and author, in his 1975 book “Systemantics: How Systems Really Work and How They Fail.” Gall was analyzing why large-scale systems—both technological and organizational—so often fail, and he observed that successful complex systems always had a history of working simplicity behind them. The law emerged from Gall’s study of systems failures across various domains, including military, governmental, and corporate organizations. His key insight was that architects and designers often believe they can plan for all contingencies, but real-world complexity ultimately defeats such comprehensive designs. The only systems that survive are those that have been tested, refined, and extended through actual use.

​
Key Points

1

Complex systems require proven foundations

You cannot jump from concept to complex implementation. Each layer of complexity must build on a layer that already works. Without this foundation, you’re building on sand.
2

Evolution beats design in complex domains

In systems with many interdependent variables, evolutionary development outperforms upfront design. The selection pressure of real use reveals problems that planning cannot anticipate.
3

Simplicity is not a phase, it's a foundation

The simple version isn’t just a prototype—it’s the core that must work. All additional complexity must serve and not undermine this proven foundation.
4

Failure is informative

When a complex system fails, the problem often isn’t the complexity itself but the absence of a working simple predecessor that was properly tested.

​
Applications

Product Development

Successful products typically start with a minimal viable product (MVP) that solves one problem well. Adding features before proving the core creates fragile products that fail under load.

Software Architecture

When designing software systems, start with the simplest architecture that meets current needs. Add complexity only when proven necessary by actual usage patterns.

Organizational Design

Organizations evolve more successfully when they build on structures that already work. Major restructuring often fails because it discards proven patterns in favor of untested designs.

Startup Strategy

Startups succeed by finding simple, proven business models first and then scaling complexity. Those that raise big funding to build complex systems before product-market fit often fail.

​
Case Study

​
The Evolution of the World Wide Web

The World Wide Web provides a compelling example of Galls’ Law in action. Tim Berners-Lee’s original design in 1989 was remarkably simple: a system of documents connected by hyperlinks, accessed through a basic browser. This simplicity—documents and links—was the “simple system that worked.” It solved a specific problem: sharing information across different computers at CERN. The system was so simple that it could be implemented, tested, and proven within a single research institution. From this simple foundation, the web evolved. Additional layers were added: images, interactivity through JavaScript, dynamic content through server-side programming, user authentication, e-commerce, social features, and mobile access. Each layer built upon a working foundation. Crucially, if the original web had tried to incorporate all these features from the start, it would have failed. The complexity would have been unmanageable, the design decisions would have been made without real-world feedback, and the system would have collapsed under its own weight. Instead, the web evolved layer by layer, each addition proven before the next was attempted. Today, the web is unimaginably more complex than Berners-Lee’s original vision—but that complexity was earned through evolution, not designed upfront.

​
Boundaries and Failure Modes

Galls’ Law has important limitations:
  1. Doesn’t apply to all domains: Some systems can be successfully designed from scratch—especially when the requirements are well-understood and the domain is constrained.
  2. Evolution requires the right conditions: The “selection pressure” that drives evolution must be real and informative. In rapidly changing environments, evolution may not have time to work before conditions shift.
  3. Simplicity can be insufficient: Some problems genuinely require complex solutions from the start. The key is distinguishing between complexity that’s premature and complexity that’s necessary.
  4. Path dependency matters: Once a system evolves in a particular direction, changing that direction becomes increasingly difficult. Early decisions constrain future options.

​
Common Misconceptions

Galls’ Law doesn’t say simple is better—it says simple must come first. The goal is eventually reaching useful complexity, but only after proving the foundation.
While evolution takes time, digital systems can evolve rapidly through iteration. The key is real-world feedback, not calendar time.
Gall’s Law doesn’t reject planning—it suggests planning should focus on creating conditions for evolution rather than comprehensive design. You plan the foundation, not the cathedral.

Minimum Viable Product

The concept of building the simplest version that can test a hypothesis—directly applying Galls’ Law to product development.

Iterative Development

Building products through repeated cycles, each building on the previous—embodies the evolutionary approach Galls’ Law describes.

Conway's Law

The insight that system design mirrors organizational communication structures—complements Galls’ Law by explaining why evolution takes particular paths.

​
One-Line Takeaway

Build a simple system that works first—then evolve it. Complex systems that succeed are built, layer by layer, on proven foundations.