What do you think?
Rate this book
Residues: Time, Change, and Uncertainty in Software Architecture
Residuality Theory is a new way to think about the design of software systems that explains why we experience design the way we do, why certain things seem to work only sporadically, and why certain architects get it right so often regardless of which tools they use. A new, scientific approach is defined that fuses Software Engineering, Complexity Science, and Philosophy to produce an entirely new way to think about how to design software. The result is a theoretical base that allows architecture to finally become its own discipline.
68 pages, ebook
Published June 2, 2024
6 people are currently reading
115 people want to read
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 15 of 15 reviews
September 18, 2025
This was as short and sweet as the paradigm setting in the field that doesn't see much of the new thought for years now. I loved it! I am still far from understanding the method well. I had to read many parts multiple times and I still feel there is much I've missed. I like this compact format indeed.
Regarding the material presented, I liked the premise that we can't possibly predict all the things our architecture might need (which also means we can't possibly find all the stressors) and that applying a statistical or, dare I say, a numerical method to something we consider a very deterministic problem.
One has to accept the fact that one is wrong a lot, until one becomes a bit less wrong.
I became aware of Barry O'Reilly when I stumbled upon his talk on NDC Oslo by complete chance. I didn't know him, nor did I like the title of his talk. I entered and sat back because I didn't know what else to listen to. I loved it! Can't wait to apply this in practice the best I can!
Regarding the material presented, I liked the premise that we can't possibly predict all the things our architecture might need (which also means we can't possibly find all the stressors) and that applying a statistical or, dare I say, a numerical method to something we consider a very deterministic problem.
One has to accept the fact that one is wrong a lot, until one becomes a bit less wrong.
I became aware of Barry O'Reilly when I stumbled upon his talk on NDC Oslo by complete chance. I didn't know him, nor did I like the title of his talk. I entered and sat back because I didn't know what else to listen to. I loved it! Can't wait to apply this in practice the best I can!
November 23, 2025
Loved it, though I don’t fully grasp the theory yet, I very much liked that the author explained irritations I have had with ‘architects’ and ‘architecture’ for a long time, but couldn’t articulate well. I have no idea if this theory will hold, but in practice I see so very little theoretically sound architecting and engineering (I do see a lot of pattern matching and cargo-cult software designing) that I very much welcome a seemingly well-founded new theory.
I also want to acknowledge that the author has taken the step to do research to help a whole field improve, that takes courage and it is risky, but even if this leads to nothing much, it is a worthwhile addition to the field. I really wish there were more incentives for smart people and the field of software engineering to do this kind of work, it is way too tempting to instead try to earn tons manipulating users into watching advertisements and paying premiums. Bravo!
I also want to acknowledge that the author has taken the step to do research to help a whole field improve, that takes courage and it is risky, but even if this leads to nothing much, it is a worthwhile addition to the field. I really wish there were more incentives for smart people and the field of software engineering to do this kind of work, it is way too tempting to instead try to earn tons manipulating users into watching advertisements and paying premiums. Bravo!
February 13, 2025
Interesting, but it feels half baked at best. My takeaway was that it’s a combo of threat modeling with architecture skipping some of the formal design. Which I like! But the text just didn’t quite work for me.
December 15, 2025
Not worth the money.
Original Concept, Broken Theory: An Unfalsifiable Manifesto of Inaccuracy and Self-Defeating Philosophy
O’Reilly's Residues is a massive intellectual frustration. It starts with a bold, essential claim: that "random simulation of stress is a better way of generating a software architecture than prediction". This promise of an architecture built for survival, not prediction, should be revolutionary. Instead, the book delivers a theory that is crippled by its own philosophical stance, rendering it unusable, unverified, and systematically imprecise.
1. A Dismissal of Effective Principles
The most damaging flaw is the book’s premise that it must discard decades of effective software design techniques and principles—like SOLID, DRY, modularity patterns, and explicit requirements analysis—only to replace them with a vague, untestable philosophy. By arguing against "prediction, requirements analysis, [and] reuse of patterns," the theory effectively dismisses the established canon without providing a verifiable, superior replacement.
2. The Core Philosophical Contradiction of Humility
The book demands architectural humility—the acknowledgement that complexity and non-ergodicity make predictive design impossible. Architects are told to abandon a priori certainty. Yet, the book itself engages in a theoretical immodesty that sabotages its own message:
- Self-Defeating Informality: The author's deliberate intentional informality is presented as necessary for engaging with complex systems. However, this choice prevents the theory from being verified or compared to alternatives, meaning the theory cannot be falsified, compared to alternatives, taught systematically, or applied consistently. The theory demands humility from the architect but refuses to submit to the humble rigor of the scientific method.
- Intuition Over Verification: The book asks architects to embrace uncertainty, but in doing so, it replaces empirical verification with untested intuition. It offers powerful ideas but refuses the intellectual work required to make them precise enough to test and apply, leaving its core concepts fundamentally vague.
3. Systematic Failures of the Theory
The absence of formalization doesn't make the theory deep; it makes it practically defunct. As a theoretical foundation, the book's contents cannot be falsified, compared to alternatives, taught systematically, or applied consistently. This is not a philosophy; it is an untested belief system.
- Definitional Chaos: The book’s most essential terms are left dangerously vague. Concepts like "residue," "stressor," "survival," and "criticality" are defined with an imprecision that makes them impossible to measure, verify, or implement in code. If the fundamentals of the theory are unclear, the entire structure collapses.
- Intuition vs. Action: The theory offers powerful intuitions but refuses the intellectual work required to make them precise enough to test, compare, and apply. It demands an entirely new mindset from the architect while simultaneously denying them the rigorous tools required to implement that mindset reliably.
- Impractical for Professionals: This inherent ambiguity creates "significant problems for comparison, systematic teaching, and consistent application." An architect cannot deploy a theory that cannot be systematically taught to their team or consistently applied across two different projects. The book is, therefore, intellectually stimulating but functionally useless.
- The Contradiction of Practice: While the book highlights genuine practical challenges (recognition, scaling, coverage), it offers a methodology that is itself unverifiable. The powerful intuitions it contains remain just that—intuitions—because the necessary intellectual work to make them precise enough for testing and comparison is entirely absent.
- Unoriginal and Vague Methodology: Furthermore, the book's signature methodology—"random simulation of stress"—offers little that is truly new or precise. At an architectural level, the approach strikingly resembles Test-Driven Development (TDD) applied at a component- or system-integration level rather than a class level. Without clear, formal distinctions, the concept risks being dismissed as a vague re-packaging of established integration testing and chaos engineering principles, thus lacking both the rigor of formal TDD and the novelty of a new paradigm.
Verdict
Residues is a massive intellectual disappointment. It identifies genuine, crucial problems in software architecture (recognition, scaling, coverage), but its proposed solution is broken by a self-defeating philosophical position. It provides a radical and needed shift in thinking but utterly fails to deliver a coherent or actionable framework. Until the profound inaccuracies and contradictions are resolved and the core concepts are made mathematically rigorous, this book should be avoided by architects looking for practical guidance. It does not even qualify as a strong philosophical manifesto awaiting a viable mathematical foundation.
If the Residuality Theory must be accepted as valid, O'Reilly must formalize his theory with more rigor than what is presented in this book and at least justify his claims with formal proofs, sound logic and maybe with a few case studies.
-------
I'll add below some (shocking, or at least surprising) quotes of the book:
1. Dismissal of Decades of Engineering Practice
These quotes justify that the book dismisses decades of effective software design techniques and principles:
- The Ultimate Dismissal: "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."
- Call for Abandonment: "This book will make the counter-intuitive case that best way is perhaps to abandon these ideas altogether."
- Extreme Analogy: "The history of software engineering thus far has been tantamount to nailing horseshoes to car tires."
- The Death of Old Ideas: "The gathering of requirements, predicting of risks, usage of patterns from the past all must die with this paradigm."
- The "Black and White" World: "traditional architectural tools such as requirements engineering, risk management, edge cases, and pattern languages have taught you to see the world in black and white, linear terms, and by learning to see your architectures as a series of residues over time you will see the world in glorious technicolor for the first time."
2. Non-Humble & Controversial Framing
These quotes frame the theory as a scientific revolution against ignorant opposition:
- The Crusader Stance: "Daring to question them brings exasperated gasps at conferences, horror and anger for those selling the latest and greatest frameworks to improve these inherited techniques."
- The Scientific Revolutionary: "Many of you may find the contents of these statements provocative and controversial, and you may even get angry! This is a completely normal reaction, predicted by Kuhn, to any paradigm shifting idea."
- Dismissal of Professional Goals: "Correctness is the goal of the programmer and the mathematician. This is one of the first major lessons a becoming architect must learn."
3. Philosophical Contradictions (Attacking Rigor)
- Attack on Rigor: "The linear thinker will demand more detail, more precision, clearer definitions, in a attempt to bring the ideas under the control of logic, but mastery lies in letting go of these demands and being comfortable with being wrong until you are right."
- Accusation of Industry Arrogance (Ironic): "Our industry has a tendency to engage in pedantic, know-it-all behaviors. The belief that a mastery of software extends to the rest of the universe is not uncommon."
- Dismissal of Historical Concerns, Not-So-Humble Unsubstantiated Attempt to Define Software Engineering: "Software Engineering is the engineering of hyperliminal systems. There is nothing in the history of engineering that is like this, and no grounds for importing historical concerns."
Original Concept, Broken Theory: An Unfalsifiable Manifesto of Inaccuracy and Self-Defeating Philosophy
O’Reilly's Residues is a massive intellectual frustration. It starts with a bold, essential claim: that "random simulation of stress is a better way of generating a software architecture than prediction". This promise of an architecture built for survival, not prediction, should be revolutionary. Instead, the book delivers a theory that is crippled by its own philosophical stance, rendering it unusable, unverified, and systematically imprecise.
1. A Dismissal of Effective Principles
The most damaging flaw is the book’s premise that it must discard decades of effective software design techniques and principles—like SOLID, DRY, modularity patterns, and explicit requirements analysis—only to replace them with a vague, untestable philosophy. By arguing against "prediction, requirements analysis, [and] reuse of patterns," the theory effectively dismisses the established canon without providing a verifiable, superior replacement.
2. The Core Philosophical Contradiction of Humility
The book demands architectural humility—the acknowledgement that complexity and non-ergodicity make predictive design impossible. Architects are told to abandon a priori certainty. Yet, the book itself engages in a theoretical immodesty that sabotages its own message:
- Self-Defeating Informality: The author's deliberate intentional informality is presented as necessary for engaging with complex systems. However, this choice prevents the theory from being verified or compared to alternatives, meaning the theory cannot be falsified, compared to alternatives, taught systematically, or applied consistently. The theory demands humility from the architect but refuses to submit to the humble rigor of the scientific method.
- Intuition Over Verification: The book asks architects to embrace uncertainty, but in doing so, it replaces empirical verification with untested intuition. It offers powerful ideas but refuses the intellectual work required to make them precise enough to test and apply, leaving its core concepts fundamentally vague.
3. Systematic Failures of the Theory
The absence of formalization doesn't make the theory deep; it makes it practically defunct. As a theoretical foundation, the book's contents cannot be falsified, compared to alternatives, taught systematically, or applied consistently. This is not a philosophy; it is an untested belief system.
- Definitional Chaos: The book’s most essential terms are left dangerously vague. Concepts like "residue," "stressor," "survival," and "criticality" are defined with an imprecision that makes them impossible to measure, verify, or implement in code. If the fundamentals of the theory are unclear, the entire structure collapses.
- Intuition vs. Action: The theory offers powerful intuitions but refuses the intellectual work required to make them precise enough to test, compare, and apply. It demands an entirely new mindset from the architect while simultaneously denying them the rigorous tools required to implement that mindset reliably.
- Impractical for Professionals: This inherent ambiguity creates "significant problems for comparison, systematic teaching, and consistent application." An architect cannot deploy a theory that cannot be systematically taught to their team or consistently applied across two different projects. The book is, therefore, intellectually stimulating but functionally useless.
- The Contradiction of Practice: While the book highlights genuine practical challenges (recognition, scaling, coverage), it offers a methodology that is itself unverifiable. The powerful intuitions it contains remain just that—intuitions—because the necessary intellectual work to make them precise enough for testing and comparison is entirely absent.
- Unoriginal and Vague Methodology: Furthermore, the book's signature methodology—"random simulation of stress"—offers little that is truly new or precise. At an architectural level, the approach strikingly resembles Test-Driven Development (TDD) applied at a component- or system-integration level rather than a class level. Without clear, formal distinctions, the concept risks being dismissed as a vague re-packaging of established integration testing and chaos engineering principles, thus lacking both the rigor of formal TDD and the novelty of a new paradigm.
Verdict
Residues is a massive intellectual disappointment. It identifies genuine, crucial problems in software architecture (recognition, scaling, coverage), but its proposed solution is broken by a self-defeating philosophical position. It provides a radical and needed shift in thinking but utterly fails to deliver a coherent or actionable framework. Until the profound inaccuracies and contradictions are resolved and the core concepts are made mathematically rigorous, this book should be avoided by architects looking for practical guidance. It does not even qualify as a strong philosophical manifesto awaiting a viable mathematical foundation.
If the Residuality Theory must be accepted as valid, O'Reilly must formalize his theory with more rigor than what is presented in this book and at least justify his claims with formal proofs, sound logic and maybe with a few case studies.
-------
I'll add below some (shocking, or at least surprising) quotes of the book:
1. Dismissal of Decades of Engineering Practice
These quotes justify that the book dismisses decades of effective software design techniques and principles:
- The Ultimate Dismissal: "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."
- Call for Abandonment: "This book will make the counter-intuitive case that best way is perhaps to abandon these ideas altogether."
- Extreme Analogy: "The history of software engineering thus far has been tantamount to nailing horseshoes to car tires."
- The Death of Old Ideas: "The gathering of requirements, predicting of risks, usage of patterns from the past all must die with this paradigm."
- The "Black and White" World: "traditional architectural tools such as requirements engineering, risk management, edge cases, and pattern languages have taught you to see the world in black and white, linear terms, and by learning to see your architectures as a series of residues over time you will see the world in glorious technicolor for the first time."
2. Non-Humble & Controversial Framing
These quotes frame the theory as a scientific revolution against ignorant opposition:
- The Crusader Stance: "Daring to question them brings exasperated gasps at conferences, horror and anger for those selling the latest and greatest frameworks to improve these inherited techniques."
- The Scientific Revolutionary: "Many of you may find the contents of these statements provocative and controversial, and you may even get angry! This is a completely normal reaction, predicted by Kuhn, to any paradigm shifting idea."
- Dismissal of Professional Goals: "Correctness is the goal of the programmer and the mathematician. This is one of the first major lessons a becoming architect must learn."
3. Philosophical Contradictions (Attacking Rigor)
- Attack on Rigor: "The linear thinker will demand more detail, more precision, clearer definitions, in a attempt to bring the ideas under the control of logic, but mastery lies in letting go of these demands and being comfortable with being wrong until you are right."
- Accusation of Industry Arrogance (Ironic): "Our industry has a tendency to engage in pedantic, know-it-all behaviors. The belief that a mastery of software extends to the rest of the universe is not uncommon."
- Dismissal of Historical Concerns, Not-So-Humble Unsubstantiated Attempt to Define Software Engineering: "Software Engineering is the engineering of hyperliminal systems. There is nothing in the history of engineering that is like this, and no grounds for importing historical concerns."
December 20, 2024
I’m extremely biased since I had been searching and waiting for something exactly like this for a long time. This book bridges philosophy and complexity sciences with software architecture addressing a profound gap in our industry.
While the ideas can be challenging if you’re not familiar with complexity sciences, they are presented in a way that’s easy to follow and implement.
Its brevity is remarkable, given the depth of content it packs. It avoids fluff and gets straight to the point, which I really appreciate. The entire writing style resonates deeply with me.
While the ideas can be challenging if you’re not familiar with complexity sciences, they are presented in a way that’s easy to follow and implement.
Its brevity is remarkable, given the depth of content it packs. It avoids fluff and gets straight to the point, which I really appreciate. The entire writing style resonates deeply with me.
July 10, 2025
This book takes explains an interesting theory about the challenges of software architecture, taking a point of view from complexity sciences and proposing a novel approach to designing solid software architectures that allow for changing environments without breaking the system.
I found the theory part to be very intriguing, offering highly entertaining food for thought that I can very much agree with. The practical part, where a set of practices was proposed, was less convincing to me. I'm not entirely sure whether the practices really reflect the best way to apply the theory, or whether they are just a set of practices that the author has found useful in his own work. However, a point that is repeatedly made is that experienced architects apply the theory intuitively without knowing it, so in a way, I feel like multiple implementations are possible and can be used to a similar effect.
The book is quite short and dense, and more similar to a long paper than a 'regular' programming book. While I appreciate the brevity, I would have benefited from a few more examples, and deeper explanations (something I seldomly feel about books). This simply means that you'll have to focus longer on the few pages that are there, and sometimes reread them to fully grasp the concepts.
Overall, I can recommend this book to anyone in charge of designing more complex software systems, in whatever capacity. Even if you don't fully implement the practices, I am sure that the theory will imprint itself on your thinking and guide you in your decisions.
I found the theory part to be very intriguing, offering highly entertaining food for thought that I can very much agree with. The practical part, where a set of practices was proposed, was less convincing to me. I'm not entirely sure whether the practices really reflect the best way to apply the theory, or whether they are just a set of practices that the author has found useful in his own work. However, a point that is repeatedly made is that experienced architects apply the theory intuitively without knowing it, so in a way, I feel like multiple implementations are possible and can be used to a similar effect.
The book is quite short and dense, and more similar to a long paper than a 'regular' programming book. While I appreciate the brevity, I would have benefited from a few more examples, and deeper explanations (something I seldomly feel about books). This simply means that you'll have to focus longer on the few pages that are there, and sometimes reread them to fully grasp the concepts.
Overall, I can recommend this book to anyone in charge of designing more complex software systems, in whatever capacity. Even if you don't fully implement the practices, I am sure that the theory will imprint itself on your thinking and guide you in your decisions.
December 18, 2024
Barry O'Reilly introduces a new paradigm to think about software architecture, drinking from the domains of complexity science and systems theory, he proposes a completely new way of approaching architecture, in a nutshell by thinking of architecture as a collection of residues that remain after a certain system has been stressed through random simulation techniques. The book is excellent, succinctly covering the theory in the first part, concisely defining all of the concepts, and then presenting the practical side of things and how you would apply residuality theory to your real-world project. With little over 60 pages, it presents the idea beautifully and makes it easy to understand, despite containing and being inspired by some pretty complex concepts. If you're working in the software industry or have any relationship with software, this is a highly recommended read, as it will give you a powerful tool to think about designing complex software systems that can be more adaptative and resilient to real-world change.
January 3, 2025
I was finally able to read the book, after that I have been following the residues theory concept and its author for a while. I believe that this new concept can bring big improvements to software architecture and that the book gives very useful observations.
Maybe I had different expectations, maybe I wasn't able to fully grasp all the concepts explained in the book, but the book wasn't fully able to satisfy my curiosity.
First of all, in several parts of the book there are references to software developers as some sort of immature people: these considerations are just out of topic and can make some developers feel criticized, and I think it could be avoided.
Even if the example at the end of the book helps in understanding the process better, the explanations still feel very abstract and not rigorous. But once again, maybe I just had other expectations.
Hopefully with a new publication these concepts will be further clarified and explained.
Maybe I had different expectations, maybe I wasn't able to fully grasp all the concepts explained in the book, but the book wasn't fully able to satisfy my curiosity.
First of all, in several parts of the book there are references to software developers as some sort of immature people: these considerations are just out of topic and can make some developers feel criticized, and I think it could be avoided.
Even if the example at the end of the book helps in understanding the process better, the explanations still feel very abstract and not rigorous. But once again, maybe I just had other expectations.
Hopefully with a new publication these concepts will be further clarified and explained.
September 28, 2025
Barry O'Reilly introduces a really interesting and refreshing way to approach Software Architecture which makes this short book worthwhile reading regardless whether you agree or disagree with his conclusions. A lot has been written about evolvable and evolutionary Software Architecture which shows how changing requirements can't be reliably predicted and we need to learn to live with this challenge. While avoiding over-engineering has become an important mantra, Barry also advocates against under-engineering and introduces some techniques for a more structured approach to build resilient architectures (although Barry most likely wouldn't use resiliency as a descriptor here).
My only pet peeve with this book is the extraordinary amount of new terminology which makes this book as pleasant to read as a PHD thesis (but at least it's fairly short).
My only pet peeve with this book is the extraordinary amount of new terminology which makes this book as pleasant to read as a PHD thesis (but at least it's fairly short).
April 10, 2025
Here's a novel approach to software architecture: Simulate stresses to a system and see what residue remains. It's literally evolutionary design, except that you simulate rather than actually develop a series of systems to see which ones are fit enough to survive.
The background and theory seems solid enough, and I suppose it's all necessary as part of selling the idea, but fortunately, in fact, the actual practice seems quite approachable.
The background and theory seems solid enough, and I suppose it's all necessary as part of selling the idea, but fortunately, in fact, the actual practice seems quite approachable.
December 14, 2025
I've seen Barry at a conference and saw him in youtube videos. The concepts this man inravels are not always plug-and-play in ly mind (re-read that paragraph once again to grasp all).
As an architect you become vigilant to not be too confident, to doubt, to see trade offs,.. but this idea - of residues - makes it more tangible for me. More of an instrument than gut feeling.
Looking forward to reading the Philosopher book he wrote.
As an architect you become vigilant to not be too confident, to doubt, to see trade offs,.. but this idea - of residues - makes it more tangible for me. More of an instrument than gut feeling.
Looking forward to reading the Philosopher book he wrote.
August 20, 2025
This book is a crucial step towards maturity in the software architecture space. What has been mostly a craft plagued by copying others “best practices”, wishful thinking and, at best, hope and luck is now rendered by Barry with a scientific foundation towards exploring and tuning your architectural decisions.
It’d also a thumping good read.
It’d also a thumping good read.
January 12, 2026
Interesting ideas presented in this book. Another look at architecture and design.
It will take time to wrap my head around the concepts but as the author states, it should be easier when applying the theory.
It will take time to wrap my head around the concepts but as the author states, it should be easier when applying the theory.
September 23, 2024
This is a great book to start your journey into the exciting field of understanding how to build software systems
February 9, 2025
Sounded very promising, but the book did not really sell the idea.
Displaying 1 - 15 of 15 reviews