Why is Everything an Edge-Case in Today’s Software?
You’ve probably seen this joke before. You’ve probably laughed at it. And if you’re a software engineer, you’ve definitely lived it.
In the real world, you are probably telling QA: “Oh don’t worry! It is an edge-case, it won’t probably happen at all”. The problem is that you know it, I know it, we both know it… it’s not an edge case, and it can perfectly happen. But we convince ourselves it will not.
But why have we reached this point? Why do we talk about cases which our software wasn’t prepared for and then we need to go afterwards and create patches, and moreover, patches that only cover that case. Then later you discover some other scenario you or your list of requirements/acceptance criteria wasn’t even thinking of.
The answer is…
Because we borrowed our architectural thinking from traditional engineering. Let’s take as an example civil engineering.
Bridges. Buildings. Things where:
- Gravity doesn’t change.
- Steel behaves the same way as it did 20 years ago.
- The blueprint captures a stable reality.
And stability doesn’t relate to software. Our software lives in what’s called a hyperliminal system, where a rigid, ordered system (your code) must survive inside a chaotic, constantly shifting context (your business environment).
One day you deploy your software solution and the next day there is a new regulation coming up, competitors lowers their price, a war breaks.
I know what you are thinking… but come on, what is the probability of those things happening? Well, let me tell you a more relatable one: your customer changes specifications in the middle of the sprint (and not once, but multiple times).
Those things can happen, and it is our world, where everything is constantly changing.
This is exactly what Barry O’Reilly realized when he formalized Residuality Theory. The main principle of his theory is:
A random simulation of stress is a better way of generating a software architecture than prediction, requirements analysis, reuse of patterns, or reactive change management by coding.
Instead of trying to predict an unpredictable future, you stress-test your architecture from every conceivable angle, without filtering by probability or “likelihood”, or how crazy it sounds. You ask relentlessly: What if this assumption is wrong? What if that definition changes? What if the context shifts here?
Here’s why this works: Complex systems don’t have infinite futures. They move between recurring patterns called attractors, specific configurations that systems return to again and again despite countless variables.
These countless variables or unpredictable things, are called stressors.
The key is that you don’t need to predict which stressor will hit, you just need to identify where the system goes when stressed, and Stuart Kauffman through its work in Boolean Networks demonstrated that there are orders of magnitude more possible stressors than there are attractors.
Let me explain it to you with an example:
Let’s say you have a restaurant. Your restaurant system could face thousands of different stressors: bookings not showing up, fraudulent bookings, payment failures, regulation changes, weather events, staff shortages, menu changes, competitor prices are reduced, pandemic restrictions, dietary requirement trends, accessibility requirements, currency fluctuations for international bookings, payment processor outages, and on and on. If you go down the rabbit hole of “what ifs”, can be infinite basically.
But this bunch of stressors don’t push your system into thousands of different states. They push it into a handful of recurring patterns or phase states, attractors.
- The “revenue protection” attractor.
- The “flexible capacity” attractor.
- The “verified identity” attractor.
- The “bidirectional communication” attractor.
And again… Why the heck does this work!?
The answer is in how we actually learn things, not how we pretend to learn them.
Think about learning a new neighborhood.
First time through, you’re staring at your phone, trying not to get lost. You follow the route given by Google Maps, but you don’t really know anything yet.
Second time, you start noticing that there is a coffee shop.
Third time, in the middle of the summer, you figure out which paths have too many mosquitos.
Winter comes. You learn which corners get icy. Walk it with a friend and they’ll point out a shortcut you walked past twenty times. Walk it with kids and suddenly you’re seeing playgrounds and ice cream shops you were blind to before.
You just walked the same route over and over, and each time you noticed something different.
This is what Deleuze was getting at with difference and repetition. We learn by circling around something repeatedly, each pass revealing what the previous ones missed.
Stressor analysis is just walking over and over again the same walk around your system.
Coming back to the beginning
The QA engineer tested beer orders. The customer asked about bathrooms.
But here’s the thing: A residual architect walks into the bar first. Before opening.
She asks: “What if customers bring kids?”, “What if there’s a fire?”, “What if someone’s in a wheelchair?”, “What if closing time gets extended?”, “What if local laws change?”
She stresses the design from every angle, not because she predicts the future, but because she’s preparing an adaptable system for an unpredictable future.
When the customer asks about the bathroom, it’s just… there. Obviously. Because someone didn’t treat it as an edge case.
In residual architecture, nothing is an edge case. Everything is just a case.
And the building doesn’t burn down.
Conclusion
If you want to explore these ideas in depth, I highly recommend reading Barry M. O’Reilly’s book called:
“Residuality: Time, Change, and Uncertainty in Software Architecture”.
In this article, I briefly highlighted Barry’s concepts in formulating his theory, and showed how they are applicable to your next system but I tried to keep it short, and skipping some of the deeper explanations to avoid making it too long.
You can get the book here.
It’s where all of this article comes from. From the mathematical foundations from Kauffman networks, the philosophical framework, and the empirical evidence that makes this more than just another architectural opinion.
I hope you liked the article!
