Why Residuality Theory resonates with me

I first encountered Barry O’Reilly’s Residuality Theory almost by accident.

I had just been at NDC in Oslo and stayed for a local user group event where Barry presented an early version of the theory.

My first reaction was that it felt unusual. The terminology and the way Barry approached architecture were quite different from what I was used to.

But there was also something familiar underneath it.

Years earlier, Juval Löwy’s Architect’s Master Class had taught me to think about architecture in terms of volatility: not just what a system needs to do today, but which parts are likely to change and how that should influence its boundaries. That idea had a lasting influence on the way I designed systems.

Residuality was clearly not the same thing, but that first presentation felt as if it was pushing further along a direction I already found compelling.

It was interesting enough that I asked my employer to send me to Barry’s full course.

That was when it clicked.

What had initially felt alien started connecting with habits I had developed over the years: repeatedly walking around a design, challenging assumptions, and trying to understand what happens when the conditions around a system change.

That is why this is not going to be an introduction to Residuality Theory. Barry has already written and spoken extensively about it, and there are much better places to start if that is what you are looking for.

This is about what I found inside it after spending more time with the ideas: what connected with the way I already worked, what it sharpened, and where I am still struggling to turn the theory into a repeatable practice.

The future is part of the problem

Software projects normally start from certainties.

We know the customers. We know what the business wants to achieve. We know how users are expected to behave. We know where the system will run. We know the regulatory constraints. We know the scale.

At least, we know all of those things until one of them changes.

I do not think an architect should design a system for an imagined future. We are not fortune tellers, and speculative flexibility has a very real cost.

But I also do not think a good architect should design only for what is known today.

The job, as I see it, is to use what we know today to get a glimpse of what tomorrow could look like.

Not to predict it.

To explore it.

This is one of the ideas in Residuality that immediately made sense to me. Barry starts from the premise that complex contexts are unpredictable and uses stress to reason about how architectures behave outside the requirements we already know.

That changes the role of uncertainty.

It is no longer noise that requirements gathering should eventually remove. It is part of the environment in which the architecture has to exist.

Do the walk

One of the parts of Residuality that resonated with me the most is Architectural Walking.

I have always had a habit of mentally revisiting designs.

I can look at the same problem ten times and discover something different on the tenth pass: a corner case, an interaction with another part of the system, an assumption I had not noticed, or simply a better way of expressing a boundary.

The important point is that the tenth look is not the first look repeated ten times.

Between those two moments I have learned things. I may have discussed another part of the system. A developer may have asked a question. Product may have clarified a behavior. I may simply have let the model sit in my head for a while.

I am looking at the same problem from a slightly different place.

A design review is an event. Architectural thinking continues afterwards.

This is probably one reason I am more comfortable with a V1 that is intended to be refined than with a disposable first design. I expect the model to evolve as I keep walking around it, but I also expect early structural choices to leave a mark.

The first line of code starts creating inertia.

That makes the cheap walks before implementation particularly valuable.

A giant lizard stomps over Stockholm

During a Residuality course, we were asked to throw stressors at the system we were analyzing.

They did not need to be likely.

Mine was a giant lizard stomping over Stockholm.

Nobody in the room was seriously planning for a kaiju attack.

That was not the point.

If Stockholm disappeared, the system would need to survive somewhere else. That led us to consider a geo-replicated deployment.

And that immediately raised another question: where would the data be replicated?

Suddenly an absurd stressor had led from regional availability to data residency and GDPR implications.

The useful part was not the lizard. It was the chain of consequences it forced us to follow.

A stressor is not a forecast.

It is a tool for discovering assumptions.

That distinction matters. Barry explicitly describes Residuality as reasoning across a large number of possible stresses without relying on their probability. The goal is not to guess which event will happen. It is to understand how the system reacts when assumptions stop being true.

Once I saw it that way, the idea felt very natural.

I was already doing this without calling them stressors

I have always asked annoying questions during architecture discussions.

What if this assumption disappears?

What if these two things need to coexist?

What if nobody consumes this?

What happens if the business changes this rule later?

Sometimes the answer is that the architecture needs to change.

Sometimes the answer is simply that the failure is acceptable.

Both are useful outcomes.

The point is not to implement protection against every scenario we can imagine. Barry makes the same distinction when discussing stressors: understanding how an architecture would respond does not mean the business has to pay for that response.

The value is in doing the thinking before deciding not to act.

Residuality gave me a more deliberate way to describe something I had been doing informally: disturb the model and observe what becomes visible.

I want the team to help me see the forest

There is one point where I differ from how architecture collaboration is sometimes described.

I do not think the whole team should design the architecture together.

I believe the architect is responsible for the design.

But the architect does not have enough information to design well alone.

What I want from the team is help exploring the dark forest.

Product sees assumptions about customers, behavior and the market that I cannot see from code.

Project management sees sequencing, dependencies and constraints that may shape what can be delivered.

Engineering management sees ownership, staffing and capability risks.

Developers see implementation friction and technical coupling.

QA sees states, transitions and edge cases that are easy to miss while thinking structurally.

Operations sees runtime conditions and failure modes that rarely appear in a feature description.

I do not want those perspectives averaged into an architecture by committee.

I want them as input so I can make a better-informed design.

That is also how I validate an architecture once implementation starts.

I often ask developers working on systems I have designed how the system feels to them: whether the concepts make sense, whether the tooling helps, whether the intended path is obvious, whether an abstraction is pleasant or awkward to use.

One danger of designing a system is becoming too fluent in your own abstractions.

Something can feel obvious only because you remember why every decision was made.

A developer who was not in your head when you designed it is a much better test.

My first team stressor analysis mostly failed

That is why I was excited to try stressor analysis with a full team.

The system was an internal project I cannot name. The session included developers together with product, project and engineering managers. Before the exercise I shared material from Barry explaining the theory and the role of stressors.

We sat around a table, discussed stressors together, and I captured them in a spreadsheet as they came up.

We generated a lot of them.

On paper, the exercise looked productive.

In practice, most of the conversation quickly converged on familiar technical disasters: loss of connectivity, attacks, database failures, infrastructure outages.

Those are valid stressors.

But they kept us exploring a relatively small and familiar set of failure modes.

Afterwards I grouped the stressors and started applying them to the architecture. A few were interesting, but most had very little effect. The architecture could already handle them.

That should have been reassuring.

Instead, it made me suspicious.

I did not think I had designed a perfect architecture. I still do not.

If a long stressor exercise does not meaningfully challenge a design, there are at least two possible explanations: the architecture is unusually good, or the exercise failed to generate enough cognitive distance from the architecture we already know.

In our case, I suspect the second explanation mattered a lot.

We generated plenty of stressors.

What we did not generate was enough variety.

A long list is not the goal

That experience changed how I would facilitate the exercise next time.

Having everybody generate stressors aloud in one stream made it very easy to anchor on whatever vocabulary appeared first. Once we started talking about infrastructure failures, the next person naturally thought of another infrastructure failure.

If I try it again, I would deliberately create divergence before convergence.

I would let people explore independently first, and I would actively ask for perspectives outside technical failure: changes in customer behavior, regulation, commercial priorities, organization, ownership, delivery constraints, support expectations.

Not because every role should stay in its lane, but because I want the different roles in the room to illuminate different parts of the landscape before everybody starts influencing everybody else.

I would also judge the exercise differently.

The number of stressors is not particularly interesting by itself.

A better question is: how many of them forced us to reconsider an assumption, boundary, responsibility or other architectural decision?

A stressor analysis that only confirms the architecture is suspicious.

Maybe the architecture really is excellent.

But I would want to make sure we actually managed to walk somewhere new before congratulating ourselves.

When do you stop walking?

There is an obvious problem with all of this.

You can always take another walk.

You can always invent another stressor.

At some point the architecture needs to become software.

I do not have a methodical stopping rule, but my intuition is based on diminishing returns.

Run an initially unbounded exploration and keep going while the exercise keeps producing genuinely new information. When new stressors start becoming variations of things we have already seen and the architecture stops materially changing, it is time to commit.

If I had to turn that into a deliberately crude rule, it might be something like: stop when ten minutes of discussion produce fewer than five genuinely new stressors.

The number is not important.

The principle is.

I do not want exhaustive analysis. I want to continue until another walk stops materially changing what I can see.

Then we build.

Code creates inertia

This is also where my practical relationship with Residuality becomes more complicated.

The theory is not limited to greenfield design. Barry explicitly describes residual architectures as being able to receive new residues later in their lifecycle.

But from a practitioner’s perspective, the economics change once implementation starts.

Code creates inertia.

Then data creates more of it. Contracts create more. Integrations, operational procedures, developer knowledge and customer expectations keep accumulating around the decisions we made earlier.

A later stressor may reveal a better architectural direction.

That does not make the migration free.

A business is not going to approve a rewrite simply because we have discovered a more elegant residue, nor should it.

So I currently find the practice most compelling before those costs accumulate: use cheap thinking early to reduce expensive surprise later.

That does not mean trying to discover the final architecture before writing code.

It means trying to make the first structural bets good enough that what we learn afterwards can usually be handled through refinement instead of replacement.

What Residuality gave me

Residuality Theory did not give me a recipe for software architecture.

That is probably one of the reasons I like it.

Instead, it gave names and structure to several instincts I already trusted.

Uncertainty is part of the architecture problem.

Walk the same problem more than once.

Disturb assumptions deliberately.

Do not confuse exploring a scenario with committing to support it.

Use other people to illuminate parts of the landscape you cannot see yourself.

And keep exploring while the walks are still teaching you something.

The theory also gave me a practice I still have not learned to facilitate well. My first attempt at team stressor analysis generated plenty of activity and much less architectural insight than I hoped for.

That does not make me less interested in the practice.

It makes me want to get better at it.

I am convinced by the thinking. I am still learning how to make the practice work.

Architecture is not about predicting the future.

For me, it is about exploring enough of the dark forest that, when I finally choose a path, I do it with fewer accidental assumptions.

Support this blog

If you liked this article, consider supporting this blog by buying me a pizza!