“Errorless Architecture” Is a Myth
errorless (adj)
Free from error, accurate, correct. Being complete of its kind and without defect or blemish.
Walk through enough architecture reviews and you start recognising a specific shape of failure. The system isn’t wrong. It’s too right. Every edge case has a handler. Every failure has a fallback. Every component is wrapped, secured, and isolated from everything else. The development cost is enormous. The operational cost is worse. And when the requirement changes, which it always does, nothing moves.
The Trap Has a Name
The implicit theory is that architecture can be made errorless: enough redundancy, enough isolation, enough fallback paths, and the system won’t fail. Everyone argues it’s about anticipating every possible flaw: a pinch of redundancy here, a teaspoon of fallback there. Secure this, protect that, isolate this, and wrap everything twice. What you actually get is rigid. Stable in a narrow band of conditions and paralysed outside it.
The confusion is between resilience and durability. Durability means strong and built to last: the system resists change. Resilience means able to absorb it.
But nothing around a system stays fixed. Systems are built by people. People change. Teams change. Business needs pivot. APIs evolve. The only constant in architecture… is change.
A system designed to resist change doesn’t win against any of that. It just breaks later and harder.
Gregor Hohpe put a finer point on it:
“Excessive complexity is nature’s punishment for organisations that are unable to make decisions.”
The overengineered system isn’t just inefficient. It’s a record of every decision someone was afraid to make.
This Isn’t New
The pursuit of errorlessness has been tried before. In the 1960s, Philip Crosby formalised Zero Defects at Martin Marietta for Pershing missile production. By the 1980s, the idea had migrated into software via Total Quality Management programmes. The NHS National Programme for IT shows what happens when the logic runs to its conclusion. Launched in 2003 to build a definitive national patient record system: every requirement specified upfront, every edge case anticipated, every hospital covered. £10 billion spent. Cancelled in 2011. Hospitals refused to use it. It had been built to be correct. It had never been built to adapt.
Toyota took a different path. The Andon cord gave any worker the authority to halt the production line when they spotted a problem. The system was designed to surface defects, not hide them. Stopping was a feature.
John Gall’s Law explains the underlying dynamic:
“A complex system that works is invariably found to have evolved from a simple system that worked.”
An errorless architecture is never simple. It starts complex and compounds.
But Sometimes It Does Work
To be precise: the errorless mindset isn’t wrong. It’s being applied to the wrong class of problems.
Safety-critical systems (aviation, medical devices, nuclear control) do design for errorlessness, and correctly so. Boeing’s fly-by-wire systems use triple-redundant dissimilar architectures. NASA’s shuttle ran five independent computers. These systems are not flexible. They are not designed to absorb change. They are designed to be correct, and when the cost of failure is catastrophic and irreversible, that’s the right target.
Commercial SaaS going down for 30 minutes is not the same as a flight control computer failing at 35,000 feet. The rest of this post is about the other 95%.
What the Job Actually Is
Grady Booch’s definition of architecture is the useful one here:
“Architecture represents the significant design decisions that shape a system, where significant is measured by cost of change.”
Cost of change is the measure. Not the number of failure modes covered, not the comprehensiveness of the fallback paths. A system that can’t adapt hasn’t passed that test. It’s failed it slowly.
This is also why the job is uncomfortable. Architects live in permanent “what if” mode: constant tradeoffs, incomplete information, pressure to decide and pressure not to. Most of that discomfort comes from trying to get the future right, when the real question is how cheaply the design can be wrong.
This is also where residuality lands. Barry O’Reilly’s framing: architectures should be trained, not designed. Apply stressors to your naive architecture. Find the attractors, the limited states the system actually occupies under pressure, then strengthen what must survive. The question shifts from “what can go wrong and how do we prevent it” to “what must remain standing when things go wrong.”
Robert C. Martin made the same point from a different angle:
“The strategy behind that facilitation is to leave as many options open as possible, for as long as possible.”
The errorless mindset closes options. Resilience keeps them open.
In Practice
Barry O’Reilly’s Residuality goes into the method. In practice, the implications are concrete.
Don’t lock technology choices before constraints are understood. Don’t cement your database schema on day one. Don’t create tight couplings because they’re faster to build. They’re always expensive to undo, and the bill arrives at the worst moment. The decisions that feel like shortcuts tend to be the ones that cost the most.
I’ve seen that movie before . It’s called “Quick Fix” and it always ends badly.
The instinct is to build monuments. Fixed, permanent, resistant to everything. The useful thing is the opposite: a system that absorbs change rather than resisting it. One that improves when things go wrong, not one that cracks under the weight of its own protection.
You don’t need an errorless architecture. You need one that can evolve, one that doesn’t punish you for not predicting the future. Those are different targets, and designing for the right one changes every decision in the process.
