The order system nobody understands ships every order. Its beautiful replacement may never ship one.
Every company of a certain age has one: the order system patched for twelve years that nobody fully understands and that somehow ships every order. Eventually someone proposes replacing it properly. The best architects write a full specification, the new design is cleaner on every page, and three years later the new system still cannot do what the old mess did on a Tuesday. Why does careful design lose to accumulated accident?
John Gall’s answer, from Systemantics (later The Systems Bible), is a law rather than a story about bad luck: 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 made to work.
Why the design loses
The old system works because each of its ugly patches was a response to a real failure. Someone’s order went missing, someone fixed that path, and the fix stayed. Twelve years of those repairs encode knowledge nobody ever wrote down, because nobody knew it as knowledge.
The redesign has to anticipate all of that in advance, and Gall names the first obstacle: It is impossible to change just one thing at a time. Every component in the new spec interacts with others, and the side effects have side effects. A simple system that works lets you discover those interactions one at a time, each against a running thing that tells you when you were wrong. A system designed whole meets all of them at once, with nothing working to learn from. That is why planning is valuable but the plan is useless: the plan assumes you can change one thing.
What the project becomes
Meanwhile the replacement project has turned into a system of its own, and Gall’s other laws describe what happens next. Systems develop goals of their own the instant they come into being. The rewrite team’s real goal quietly shifts from replacing the old system to keeping the rewrite funded. People in systems do not do what the system says they are doing.
The project grows, and Gall has a law for that too: As systems grow in size and complexity, they tend to lose basic functions. It holds steering meetings and monthly status reports. Just calling it “feedback” doesn’t mean that it has actually fed back. Those reports measure progress against the plan, and the plan was written by the people reporting on it. Gall’s advice is to Look for the self-referential point. That’s where the problem is likely to be. A project that grades itself by its own criteria can stay green for years, because in complex systems, malfunction and even total non-function may not be detectable for long periods, if ever.
Pessimism or diagnosis?
It is easy to read all this as cynicism. But Gall’s laws are not pessimism but diagnostic tools. They tell you where to look when a system fails and which repairs not to attempt.
The strongest objection is to the word “invariably.” Some designed systems do work, such as bridges and aircraft. But they rest on long-evolved knowledge of materials and earlier machines, so the design is new in its arrangement, not its foundations. Gall overstates the law in a useful direction: the more of a design that is new at once, the less of it will work.
Which brings the company back to the order system nobody understands. Before replacing it, the most useful thing anyone can do is watch what it actually does, which is different from its documentation and from what its owners believe it does. The system is its own best explanation. The question is whether anyone will read it before deciding it has to go.
References:
- John Gall, The Systems Bible: The Beginner’s Guide to Systems Large and Small (originally Systemantics)