Gall's Law
Introduction#
In 1975, John Gall published Systemantics, a book about how systems behave and fail. One observation from it became known as Gall’s Law:
“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, beginning with a working simple system.”
Gall wrote about systems in general. The law fits software closely, and it applies twice. It governs the code being written, and it governs the team writing it.
Why Systems Built From Scratch Fail#
A complex system has many parts, and most of its behavior comes from how those parts interact. When every part is built before any of them run together, each interaction is an untested assumption. The first integration tests all of them at once. When something fails, the cause could be in any part or any connection between parts.
A simple system that works has few interactions, and each one has been exercised. Adding a capability adds a few new interactions. If the system breaks, the cause is almost always in the change you just made. You know what the system did before, so you can tell what the change did.
This is the mechanism behind the law. Complexity grown from a working base is verified one step at a time. Complexity designed up front is verified all at once, usually when problems are most expensive to fix.
Applying It to Software#
The practical question Gall’s Law raises is what to build first. The answer is the smallest version of the system that does something useful from start to finish and produces a result you can check.
A walking skeleton is one way to build it. It connects every major part of the system to perform one narrow function end to end. It does very little, but it works, which makes it the simple system Gall describes. Every later change grows from it and can be checked against it.
Order matters here. Building each layer to completion before connecting them is designing from scratch, even when the layers are built one after another. The skeleton puts integration first, so the system works at every step after.
The Team Is a System Too#
The engineers building the software form a second system. They divide work, combine changes, review each other’s code, and decide when something is ready to ship. Those activities have parts and interactions of their own, and the same law applies to them.
A team that starts with a large parallel effort tests all of its coordination at once. Mismatched assumptions about a shared interface, slow handoffs, and unclear ownership surface together at the end, when they are hardest to untangle.
A small first change gives the team a simple working process to grow from. That change exercises how the engineers coordinate, integrate, and verify. Problems appear while the change is small and the cause is easy to find. The team adjusts, and the next change runs on a slightly better process. Each increment grows the software and the way the team builds it.
Conclusion#
Gall’s Law asks where a working system begins. For software engineers, the answer shapes both the code and the team. Start with something small that works end to end. Change it one step at a time, and let what each step reveals decide the next one.