A few years ago, I worked as an architect on a big mainframe rewrite. I still count it as one of my failures. Not because the technology was wrong, but because I couldn't convince the management team to simplify the approach. Years later, the organization is still struggling to get the new system up and running. I left the project at the time, because I couldn't put my name behind an approach that would take very long and cost a lot of money without a working system to show for it along the way.
Gall’s Law
That memory keeps coming back to me, because it's a textbook case of Gall's Law playing out in real life.
Gall's Law, from John Gall's Systemantics, states it plainly:
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 it cannot be patched to make it work. You have to start over with a simple system that works.
What does that mean in practice, beyond a quote you nod along to?
The proposal that got rejected
The product owner and I proposed an incremental approach. Start with a small, functional slice of the new system, get it live, learn from real usage, then grow it from there. Management turned it down. They wanted the full replacement built and mapped out before anything went live, every module and integration designed up front as one coherent whole. On paper that looks thorough. In practice it means you don't get real feedback until the very end, when the cost of being wrong is highest.
When I dug into why management insisted on the all-at-once approach, it wasn't really about completeness. It was fear. They were convinced the business would not accept a first version with only a minimal set of features. Years of working with the current system had made everyone risk-averse about touching it at all, so the plan became: don't ask the business to accept anything until it's "finished". That sounds cautious. It's actually the riskiest possible strategy, because it bets the entire project on getting a massive, never-tested system right in one shot.
No working core to learn from
A simple system that works gives you something to observe. Real usage patterns, real data quirks, real failure modes. Skip that stage and you're designing hundreds of components against assumptions instead of evidence. I pushed for carving out a small, functional slice first, something that could go live and take a fraction of the real workload, even if it meant the business had to accept an incomplete tool for a while. Management preferred to protect the business from that discomfort entirely. That disagreement is why I left.
Complexity has to be earned, not front-loaded
The mainframe system had grown complex over decades because it had evolved, one working increment at a time, shaped by real requirements as they showed up. The rewrite tried to design that same complexity from a blank sheet, without the years of real-world pressure that had actually justified each piece of it. That's the trap. You can't shortcut evolution by out-designing it.
What I tell teams now is simple:
If you can't get a small, working version live first, you don't yet understand the problem well enough to design the big version.
That's not a lack of ambition, it's a precondition for it.
And if the real objection is "the business won't accept something minimal", that's worth naming honestly instead of hiding behind a bigger design. Avoiding that conversation doesn't make the risk go away. It just moves the risk to the end of the project, where it's far more expensive to discover you were wrong.
Years later, the organization is still stuck trying to get the from-scratch system to work.
Gall's Law doesn't care whether you believe in it or not...
More information
John Gall, Systemantics: How Systems Work and Especially How They Fail