errorless (adj)

Free from error, accurate, correct.
Being complete of its kind and without defect or blemish.

I stumbled lately onto a strange feeling: many of the architectures I review are overcomplicated, fragmented, full of flows jumping here and there.
And what makes it worse? The costs of development, the deployment, the running, the operations — just to keep the system alive — are astronomical.

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.

However, instead of ending up with “a state-of-the-art design,” as they expect, they end up with rigid, overengineered systems that are at best… stable.
But there’s one thing they all forget: Adaptability.

I know some will start waving the flag of “clean architecture,” “decoupling,” or “microservices.”
But for me, it’s deeper than that.

“A good architecture isn’t about being errorless; it’s about being resilient — able to adapt without drastic changes to the whole system.”

The problem is, most people confuse resilience with durability — as in strong and built to last a long time without breaking or becoming weaker.
But we all know that “errorless” and “flawless” design are myths.
Systems are built by people. People change. Teams change. Business needs pivot. APIs evolve.

The only constant in architecture… is change.

I’ve learned this the hard way, like most of us.
You build something, it works, it’s elegant — and then comes the change. A new requirement, a new constraint, a new team, or just time doing its thing. Suddenly, your “errorless” perfect design becomes your worst enemy.
It can’t bend. It can’t adapt. It can only break.

That’s when you realize: the value of architecture isn’t in what it prevents — it’s in what it absorbs.

To me, resilience means building systems that bend without breaking.
It’s the difference between tweaking a config and rewriting half your platform because of a new requirement.

Grady Booch said it best:

“The best architectures are those that can evolve gracefully under stress.”

On the other hand, architecture is stressful.
We, architects, are judgmental. The job is judgmental. Constant tradeoffs. Incomplete information. Pressure to decide. Pressure not to.
We live in a constant “what if” mode.

residuality

Which is where residuality, from Barry O’Reilly, comes in. And I love how he frames it:

“The best design is the one that leaves the fewest irreversible decisions.”

Residuality means designing for change — before change even happens.
It’s like laying down tracks but keeping the junctions open.

Don’t commit to tech too early.
Don’t lock your database schema on day one.
Don’t create tight couplings just because “it’s faster.”
These decisions always come back — like bad karma — and they’re expensive to undo.

We act like we’re building statues.
But what we really need… are sponges.

I also want to highlight that resilience isn’t about being bulletproof. It’s about being flexible.

Stability might look safe. But it can kill adaptability.
That’s a trap in systems thinking: we add more structure to “fix” problems, and end up with a system that can’t move.

Or worse: a system that silently fails in the background while we admire its layers.

Fixes that fail? Seen that movie.
It’s called “Quick Fix” — and it always ends badly.

You want a system that can stretch. A system that learns.
One that gets better when things go wrong — not one that cracks under the weight of its own protection mechanisms.

So no — you don’t need an errorless architecture.
You need one that can evolve. One that doesn’t punish you for not predicting the future.

Because at the end of the day, real architects don’t fear change — they’re built for it.