Residuality: A Paradigm Shift (Part 1)

Barry O'Reilly is the Founder of Black Tulip Technology and the inventor of Residuality Theory. In today’s podcast, we discuss his journey in questioning mainstream software architecture. O'Reilly explains his realization that real-world software development often diverges from theoretical models.

He details his path toward formulating Residuality Theory, driven by observing patterns in successful architectures that emerged from stressed models rather than fixed requirements. This led him to pursue a PhD to scientifically verify his observations, encountering initial skepticism before gaining acceptance, particularly among developers.

The conversation touches upon the fundamental problem of designing static software for a constantly evolving environment and how Residuality Theory offers a different perspective by considering a system's possibilities across time.

Barry, a veteran of the software industry, shared his journey of questioning mainstream thinking in software architecture, a journey that ultimately led him to entrepreneurship and the pursuit of a PhD. It was a fascinating conversation that challenged many of the assumptions we hold dear in our field.

Barry recounted how his path diverged from conventional wisdom. He realized that his actual work on real projects bore little resemblance to the theories and methodologies taught in books. This discrepancy became particularly apparent when he was tasked with training a new generation of architects. When asked what he should teach them, the simple yet profound question, "teach them whatever it is that you do," sparked a period of intense self-reflection. Barry admitted that he didn't have a clear, codified process, but rather an intuitive way of assessing situations and adapting his toolkit. This realization, that his practical approach was much "looser" and "more fluid" than established theories, set him on a path of inquiry.

As Barry sought to understand his own process, he ventured down intellectual "rabbit holes," one of the most significant being the discovery of Nassim Taleb's work. Taleb's perspective, particularly from "Fooled by Randomness," resonated deeply with Barry. He recognized the tendency in the software industry to create comforting narratives that mask our inherent uncertainty. Barry argued that much of established architecture felt like these "stories" we tell ourselves to feel less "scared of the dark".

This realization fueled Barry's desire to move beyond speculation and seek a more grounded understanding of software architecture. He observed that the software industry, especially after the 1960s, seemed to have lost its connection with academia and the need for empirical validation. This lack of rigorous proof allows "outlandish statements" to gain traction and become widely accepted without verification. Barry expressed his desire to do things differently and contribute to a more scientifically sound foundation for architectural thinking.

Barry's early attempts to share his unconventional ideas at enterprise architecture conferences were met with skepticism and even "rejection". He likened the experience to being a "fox in the hen house". He recognized that the industry is deeply invested in established ideas, some of which have been around for generations. Questioning these deeply held beliefs can be met with strong resistance, as people can anchor their identities to these concepts.

A significant turning point came through an encounter with researcher Vincenzo De Florio, which led to the publication of one of Barry's articles in a workshop proceeding focused on anti-fragility. This marked the beginning of differentiating his ideas through academic engagement. Instead of continuing to try and convince architects, Barry shifted his focus to developers, presenting his ideas at developer conferences like Domain Driven Design Europe. This change in audience proved pivotal, with developers showing more openness and curiosity. The publication of his book "Residues" further amplified these ideas and made them more accessible to a wider audience. While some initial pushback still occurs, Barry welcomes it as a way to strengthen the ideas, noting that after a decade, few truly novel counterarguments are emerging.

When asked about the fundamental broken idea in mainstream software architecture, Barry offered a nuanced perspective. He doesn't believe anything is inherently "broken," but rather that the rapid pace of speculation, fueled by excessive marketing, outstrips scientific verification. This leads to the premature adoption of ideas that are not fully fleshed out or scientifically validated. However, a core underlying challenge, in Barry's view, is the inherent mismatch between the static nature of software and the constantly evolving world in which it operates. Software, being a machine, lacks the inherent flexibility of human systems and is therefore fundamentally "brittle". Despite the common perception of software as malleable, once in production, it can only execute what it was explicitly programmed to do.

The engineering paradigm, with its focus on upfront requirements, component diagrams, and architectural patterns, attempts to manage the inherent instability. However, Barry, drawing on the work of Thomas Kuhn, suggests that this paradigm is facing anomalies it cannot adequately address, leading to its potential collapse. Residuality offers a fundamentally different perspective. Instead of viewing a software system as a collection of interconnected components, it posits that an architecture is a set of interconnected possibilities across the entire lifecycle of the system, existing even across time, space, and probability.

The "residue" becomes the unit of analysis, representing how a system collapses at a particular point in time. This view challenges linear, logic-centric thinking and embraces the inherent uncertainty of software evolution. Residuality provides a framework and even mathematical explanations for understanding and working with this temporal spread of possibilities, offering a way to design more resilient architectures.

Interestingly, while seemingly abstract, the principles of Residuality often resonate with junior engineers who find it intuitive, and with senior engineers who recognize it as reflecting their implicit, experience-driven approaches. The challenge has been the lack of a formal language or tooling to express this dynamic view of architecture. The reactive "all hands on deck" mentality and over-reliance on incident management in the face of frequent production issues are symptoms of the limitations of the prevailing paradigm.

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

Barry’s answer and other interesting questions to be discussed in Part 2 of the podcast. Stay tuned for the next episode…

Members of the Cyb3rSyn Community can watch the podcast episode on the www.cyb3rsynlabs.com portal or the mobile app (iOS and Android).

The podcast episode is also available here:

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 another link to Barry’s latest book, The Architect’s Paradox.