When building a new service, there are moments when you want to draw up a perfect system with every feature from the start. Designing member management, payments, recommendations, and analytics all at once and finishing them in one go seems far more efficient. Yet the bigger a project starts, the more often it never quite works. The rule of thumb that sums up this phenomenon in a single sentence is “Gall's Law.”
Put simply, Gall's Law is the principle that “a complex system that works has always grown out of a simple system that worked.” It was coined by the American pediatrician and author John Gall while studying the ways systems fail, and today it is often quoted in software design and product development.
In this article, we will look in turn at where Gall's Law came from, what its three sentences mean, real-world examples, and how to follow the law in practice.
How Systems Grow from Simplicity to Complexity
A Systems Story Written by a Pediatrician
John Gall was a pediatrician who treated children in Ann Arbor, Michigan, for more than 40 years, and he also worked as a clinical associate professor of pediatrics at the University of Michigan. His main work concerned children's development and behavior, but he set aside time to collect cases of why systems large and small do not behave as expected.
- First book (General Systemantics): In 1975, he published the failure cases and lessons he had gathered in a book titled General Systemantics.
- Reissue (Systemantics): Two years later, in 1977, it came out again under the title Systemantics: How Systems Work and Especially How They Fail and was widely read.
- Revised editions (The Systems Bible): A second edition nearly twice as long appeared in 1986, and in 2002 a third edition was published under the title The Systems Bible.
Like Murphy's Law or the Peter Principle, the book explained the properties of systems in short, witty sentences. The most famous of them later came to be called “Gall's Law” among readers. In the book itself, however, it bore no such name.
The Three Sentences That Make Up the Law
Gall's Law is usually quoted as a single idea, but the original consists of three connected sentences.
(1) A successful complex system has a simple starting point
If you trace a complex system that works back to its origins, you always find a simple system that worked. This means complexity is not designed from the start but accumulates little by little while the system keeps working.
(2) A system made complex from the start cannot even be fixed
Gall asserted that a complex system designed all at once from scratch never works and cannot be brought to life by patching it up. That is because no one can know in advance how all the parts will interact. A design that looks perfect on paper, once its parts actually start meshing and running, sees unexpected conflicts erupt everywhere at once.
(3) You have to start over with something simple
The solution, then, is just one: build a new simple system that works and grow it again from there. Even if the effort already spent feels like a waste, starting over small is ultimately faster than clinging to a huge design that does not work.
Gall did, however, preface these sentences with the caveat that a simple system may or may not work. Simplicity does not guarantee success; his point was that successful complex systems started out simple.
Examples That Show the Law
Gall's Law spread into information technology as system designers quoted it. Systems designer Ken Orr introduced the sentence early on in 1981, and from 1991 the object-oriented design authority Grady Booch quoted it repeatedly in several books.
The World Wide Web, Which Started Small and Grew
The World Wide Web began with a very simple structure: linking documents to other documents. At first it was a tool for researchers to share materials, but images, search, shopping, and video were added one after another on top of that working skeleton until it became today's enormous system. Precisely because not every use was fixed from the start, new features could settle in naturally.
Standards Designed Huge from the Start
By contrast, complex technical specifications that tried to cover every case from the start have often failed to take hold in practice. CORBA, a distributed object standard for connecting different programs, is often cited as an example that began with a massive specification and never came into wide use.
How to Follow Gall's Law in Practice
Gall's Law fits well with Agile Software Development, which builds in short cycles and revises often. Extreme Programming in particular advises building the simplest thing first and adding features later.
(1) Build the smallest finished product first
Even with few features, first release a minimal product that actually works from start to finish. Adding only what is needed while watching how users respond cuts down the effort spent on useless design.
(2) Always keep it in a working state
Each time you add a feature, check that the system still runs properly. Making small changes and testing them right away, rather than changing a lot at once, also makes it easier to find the cause of a problem.
(3) Beware of hugeness built in a hurry
These days, AI coding tools make it possible to build large systems in an instant, but assembling something quickly does not let you escape the failure Gall described. The faster things move, the more important the principle of starting small becomes.
Gall's Law is not telling us not to build complex systems; it is advice that there is a proper path to complexity. One small system that works properly today will take you further than a big, impressive blueprint.
Building small, making it work properly, then growing it one step at a time — that is the first step toward a sturdy system.
