I’ve been absent from this space for a while. The workload over the last few months has been brutal, and frankly, my brain has barely had enough bandwidth to process the day, let alone write about it. I know it’s not a justification, but sometimes silence is just a sign that you are trying to keep your head above water.

Anyway, I’m here now.

I have spent years fighting with diagrams. Perfect little boxes. Straight arrows. Microservices that promise decoupling and databases that swear on consistency. On paper, everything makes sense. In the architecture review meeting, everything fits.

But then Monday arrives. Or the end of month closing. Or that legacy migration deadline that was impossible from the start. Or that requirement change that no one saw coming because the business decided to pivot three degrees to the left. And suddenly, that rigid, beautiful structure becomes irrelevant. It breaks. Or worse, it becomes a burden.

I always believed the failure was mine. That if I had gathered requirements better, if I had understood the domain deeper, the system would have held up. It is the impostor syndrome whispering that a “real” Architect would have foreseen the unforeseeable.

But recently I stumbled upon a concept that named something I intuited but could not articulate. Residuality Theory. And suddenly, I felt a weight lift off my shoulders.

The problem is that we were taught to treat software as if it were civil engineering. As if we were building static bridges. But software, especially the software that supports complex businesses, is not static. It is a living, chaotic system, full of what the theory calls “attractors.” Hidden states toward which the system inevitably gravitates, whether we want it to or not.

The idea is brutally simple and yet terrifying for those of us who love control. Instead of designing a “perfect” architecture based on what we know today, we should design a “naive” architecture and stress it. Torture it. Throw random scenarios at it. Problems that haven’t happened yet but could.

Not to see if it holds up. But to see what is left.

The “residue.” What survives the stress. That is the true architecture.

It is a paradigm shift that hurts a little. It means admitting that we cannot analyze everything. That the complexity of a distributed system, added to the human complexity of a business, makes it impossible to predict every interaction. Trying to reduce the world to boolean logic is a losing battle.

What this theory proposes resonates with what I have seen in production over the last nine years. The architectures that work best are not the ones that tried to guess the future, but the ones that were trained to survive the unknown. It is almost like machine learning. You don’t design the rules; you train the model. Here, you don’t design the final solution; you train the structure so the “attractors” don’t destroy it.

It makes me think about how we manage our own lives.

We build plans, careers, expectations of where we should be in our mid thirties. Rigid structures. And then life throws random stress at us. A loss. A crisis. A silence. And the plan falls apart.

And what remains after that, what survives when the original plan turns to dust, that is our true structure.

Maybe in code, just as in our days, it is not about building something that never fails. It is about building something that, when it fails, leaves a residue upon which we can keep building.

Accepting that we don’t control the variables. That chaos will get in. And that architecture is, simply, what is left standing when the storm passes.