Residuality: A Paradigm Shift (Part 2)

Recently, I had the incredible opportunity to sit down with with Barry O'Reilly and chat about his work on Residuality theory and his call for a paradigm shift in software architecture.

In Part 1, we discussed his journey in questioning mainstream software architecture and his path toward formulating Residuality Theory, driven by observing patterns in successful architectures that emerged from stressed models rather than fixed requirements.

This newsletter brings Part 2 of that conversation. In this exclusive episode, Barry explains how his approach to architecture fundamentally differs from traditional risk management within the engineering paradigm.

He posits that focusing on predicting known risks makes systems fragile, while his method uses random simulation of potential system states to train architecture for criticality, the ability to survive unexpected conditions.

O'Reilly also discusses the philosophical underpinnings of software engineering, arguing that the ingrained logical and engineering mindset can hinder the adoption of new paradigms like residuality, which acknowledges inherent uncertainty and the limits of models.

He also provides an excellent parting advice for budding technologists that differs from conventional “networking” advice or career strategies.

At Cyb3rSyn Labs, we explore multidisciplinary ideas that are pertinent to technologists. As part of my own explorations, I’ve found that insights from complexity rocks the very foundational ideas on which mainstream software engineering rests.

Barry’s work is a result of taking complexity seriously and thinking about its implications on software architecture. Here are some key insights from our chat:

My own background in cyber security naturally led us to a question about the relationship between Residuality and established practices like risk management and threat modeling. How is it different?

Barry immediately addressed the common reaction he gets from people, particularly those in cyber security and risk management, who say, "Hey Barry, like we already do this, why is this different?". He explained that this reaction is perfectly human and natural for people working within an existing paradigm. Drawing on Thomas Kuhn's work in "The Structure of Scientific Revolutions," Barry noted that the people in the old paradigm will often insist they have things covered and there's no need for further thought. "I don't need to put any energy into this. I already know this". This response allows them to turn the new idea into a non-threat by saying, "Look, this is just the way things have always been. This is nothing new". Barry gets this response a lot, especially from risk management people. He notes that you can always find something slightly similar in a paper from the past and claim it was already discovered.

Barry posits that residuality theory offers a fundamentally different paradigm compared to traditional risk management and engineering approaches. While engineering often focuses on designing a system to survive in a very specific set of conditions, residuality is about building a system designed for conditions that you don't understand or know. This makes it different from engineering, which is typically predictable, certain, and controllable.

Instead of predicting the future and taking actions against those predictions, residuality theory focuses on training the system. It involves random simulation of the business environment, leveraging the enormous imbalance between the potential states of a complex system and the combinations of properties within it. Software, being incredibly constrained and structured from transistors up to error handling mechanisms, has a reduced number of possible states compared to reality's potential combinations. Residuality uses random simulation to leverage this imbalance.

The goal is to train the system until a property Barry calls criticality emerges. This criticality can be related to Nassim Nicholas Taleb's concept of antifragility, although Barry notes that resilience is slightly different. Criticality is the ability of a system to survive in an environment it's not prepared or designed for, surviving "off-spec" conditions. This ability to survive off-spec is something that can be clearly measured, providing engineers with a tangible result.

Barry is quite critical of traditional methods, viewing them as part of the engineering paradigm focused on point prediction.

Risk Management is seen as fixing for a specific, known 'X' and guaranteeing survival against it. It involves trying to find the impact and probability of things in an unknowable future using spreadsheets, which Barry sees as creating a different kind of “requirement” and deliberately making the system fragile. Assigning probabilities like less than 10% and excluding them is based on biased pictures.

Edge Cases are seen as an "incredibly arrogant statement". Barry argues that models of a system are deeply flawed, tiny chunks of reality that are constantly invalidated. Calling something an "edge case" implies the model is perfect except for these insignificant things that don't require much energy, often managed as risks (another form of requirement) within the engineering paradigm.

Scenario Analysis is described as a collective effort to predict what's likely to happen, another way to talk about requirements, and again, involves point predictions of the future.

All these traditional ideas, from a residuality perspective, involve point predictions and are rooted in a paradigm where systems are designed to requirements, which Barry argues inherently makes them fragile. Residuality aims to break down the point prediction engineering paradigm process of risk management.

A significant part of our conversation explored the philosophical underpinnings of software engineering and why engineers might struggle with new ideas like residuality theory. Barry realized that people were often philosophically unprepared. He argues that software engineers are often not fully aware of their own philosophical view of the world because they aren't taught this; they take it for granted. The education system often treats philosophy as something separate from "real work".

Barry traces the roots of this mindset back through computer science professors to logicians like Frege, Russell, Wittgenstein, and Turing, and fundamentally, to Plato. The logical, certain way of viewing the world taught in computer science, though necessary, becomes limiting when applied to complex social or human systems where logic doesn't always work. This "hardcoded logical way of thinking" can lead to an inability to see things from a different philosophical position.

His latest book, "The Architect's Paradox," dives into this, showing software engineers how philosophical ideas turn up in their work. It serves as an introduction to philosophy for engineers, encouraging them to reflect on how they got here and why they think the way they do.

Barry is remarkably philosophical about the future of residuality theory once it's released into the wild. Given his work in complexity sciences, he has no expectation or need to control the idea. People will naturally blend it with other ideas; it fits well with Domain Driven Design, for instance.

He fully expects people to use it in their own ways, some well, some in ways he never thought of, and even in seemingly contradictory ways. He's already seen people trying to turn residuality into a step-by-step process (A ➡️ B ➡️ C and then residuality), despite the theory suggesting there is no such linear process. Residuality won't be the final step; new ideas will emerge when different concepts accidentally intersect.

Barry's goal isn't to be a referee dictating the "true" message. What he's trying to do is shape the thinking of the industry, which will create a thousand different ripples. Every person who uses residuality is a different ripple. Some ripples will survive, others will prove foolish, but the ultimate goal is the change in conversation – getting people to think differently and move out of the engineering paradigm. He is comfortable that his ideas will be warped and changed by technology and new concepts he hasn't even considered. He sees himself simply as a pebble in the pool, not the designer of the pool or the director of its flow. Ideas are meant to be "corrupted," and Barry welcomes it, even hoping someone will break his ideas down eventually.

Barry offered powerful advice for budding architects and everyone in the industry: the most important thing in your career is integrity – being yourself all the time. His own career has been driven by following his nose and doing what he finds genuinely interesting and fun, rather than chasing goals, titles, or valuations.

He contrasted this with the "networking nonsense" and shallow approach of trying to climb the ladder through inauthentic means. He believes that when you are genuinely interested in what you do, you don't need to strategize about networking or climbing the ladder; happiness comes from doing what you think is cool, and success becomes a side effect. Trying to succeed by being inauthentic is working against "the dice of the universe" and can lead to being "rich and sad".

Here is my 2 cents: As I added at the end of our conversation, innovation happens at the frontier, not in the mainstream. So, chase your curiosity and look at what's happening on the frontier. Please don’t copy residuality as a method, but try to understand the principles and the philosophy that underpin its work - it truly calls for a radical shift in our worldview. From that lens, Barry’s latest book is a recommended read.

Here is the link to an exclusive 50% off discount of Barry’s first book, Residues: Time, Change, and Uncertainty in Software Architecture.

For the Premium Tier members, below is the full podcast episode and a 50% discount link to Barry’s latest book, The Architect’s Paradox.