Root Cause of Architectural Thinking

Nune: Welcome to Root Cause. I'm Nunem. This is where we get to the root cause of things. Architectural decisions that aged badly, leadership transitions nobody prepares you for, and the hype cycles that keep repeating themselves. If you have ever thought, am I crazy for questioning this, you're in the right place. In one of the previous episodes, I confessed to struggling between the role of the architect and the role of the implementer. For me, those are very often inseparable. I need to design what I'm building.
Barry: .
Nune: And I want to build what I've designed to improve it. This got me thinking: what is even the role of the architect? Is it really a separate job? Is it a skill of a software engineer? My guest has said it, and I agree, most of us operate on gut feeling. And from outside, that looks like magic, as anything complicated enough does. And although I deeply enjoy the feeling that I'm a magician.
Barry: Thank you.
Nune: As a person who also likes structure, when I realized Barry is attempting to structure this magic, I was hooked to listen to his talks. So when my friend, with whom I've shared his talks before, asked me to invite my guest, to be honest, I had two concerns. First, what if he doesn't And second, what if he answers? The first concern was because I think Barry's theory is something younger generation of software engineers will be studying in universities. And you know, who am I with my two episodes for him to answer? And the second concern was what if he answers ⁓ and I don't know enough of his theory to keep the conversation up. Then I realized I must not be an expert of it. I just need to be myself, ask naive questions, and the qu and the conversation will help us understand the theory better. So I'll be the guinea pig today and let's figure this out together.
Barry: . .
Nune: Let me give him a proper intro. My guest today is Barry O'Reilly, 25 years in software architecture. He held chief architect positions at Microsoft and was the global leader for their solutions architecture community. He's been a startup CTO himself. He's helped companies make sense of messy architectures, and has eventually become the person you call when you need to solve a problem. At Microsoft,
Barry: Okay. Thank you.
Nune: Barry was asked to train junior architects in how he did his work, and he discovered he couldn't describe his own methods. So much of it was gut feeling, built up over years, that he had nothing concrete to hand to a junior. He talked to other architects who consistently got it right and found the same thing. They were all running on instinct they couldn't articulate. Most people would have shrugged and called it talent.
Barry: . Okay.
Nune: His frustration has led him to try to organize his knowledge into a philosophy, and for the last several years he's been finishing a PhD in complexity science and software design. His theory is called residuality theory, and today we'll try to figure out what it is and how to apply it. Barry, welcome to Root Cause, and it's an honor to have you. So ⁓ I wanted to start with something that I discovered that we have in common and it's not a typical thing among ⁓ engineers. this is that we both studied mathematics ⁓ and not applied mathematics, but theoretical, complex analysis, linear algebra, ⁓ differential geometry, topology. And we both yet ended up in software engineering. ⁓ and I'm still honestly not sure if the math background helped me or damaged me in some in r unrecoverable ways. ⁓ what do you think? Has it helped you or was it a trap?
Barry: I think that it has definitely helped me, but I can only say that in retrospect, looking back over my career, ⁓ original ⁓ education in pure mathematics, ⁓ it helps you to look at the world in a particular way, which I think is much broader and much more abstract than the kind of, followed up my math education with undergrad and post-grad work in software engineering. ⁓ And I find those subjects, obviously they're useful because we built software, but they don't have the same kind of abstract capacity as pure mathematics. I think that's maybe one thing that's helped me look beyond the code, look beyond the software. ⁓ And it sets in motion a set of a way of thinking, a way of looking at the world. Which as you've probably seen in my second book, I try to escape as much as possible. ⁓ But it does set you up for it. It teaches you how to think, which I think is incredibly important and something that's maybe not as widespread in our industry as it should be.
Nune: Yeah, I agree. I've I've reflected over the years a lot, and there were some periods that I regretted not having specifically computer science ⁓ education, maybe because of the ⁓ basic algorithms that they teach you there or how computers work. ⁓ this has all been like taught by trying on my side. On the other hand, with mathematics you get this way of thinking and also way of learning. Like you suffer so much through these abstract theories that you learn to sit with something long enough ⁓ until you get it.
Barry: Yes. I think also that capacity to structure the world around you, to very quickly decide what can be reduced and structured and what has to be left to mystery. That's been a big help to me, I have to say.
Nune: It o it also has made me n this overthinker, ⁓ the person who li who looks at the problem ⁓ at too many angles. ⁓ and for for a long time I had this note on my desk, think less, do more, which is sort of ⁓ the reverse of what people usually advise to themselves, like to think and then do. And I think a lot of a lot of it also comes from this ⁓ so called agile mindset that you need to do in order to discover. what do you think should we think before doing or should we do and discover ⁓ how to think?
Barry: Yeah, I think that, you know, everyone in Silicon Valley must have had the same post-it note for the last 20 years because there really is a dearth of thinking in this industry and it's a problem. ⁓ see in my consultancy work, unfortunately in my career, I've got this reputation for project rescue. So I come in when things are on fire and I see an industry where doing is . prioritised over thinking and it has disastrous effects on the quality of software ⁓ that is And that's going to become a bigger and bigger problem for us over the coming years. ⁓ And I think that there really needs to be an emphasis on thinking because when we look at, when I look at these senior architects and my own practice, I say, what is it that we do that's different? What is it that the senior architect who succeeds? with their architecture, does, that the junior architect doesn't do. And the answer is always thinking. They learn how to think about something deeply, how to distill their thoughts and how to turn those thoughts into something useful at the end of the day. But there has been in the industry an emphasis ⁓ and a preference for action and do not think later. ⁓ move fast and break things, which has become the sort of dominant culture of the software industry. And that is not moving the needle. You know, we still have the same issues we had back in the 1960s with regards to software quality. ⁓ Even though we're shipping a lot more software and from a certain perspective, we're but we're shipping loads. So we must be solid. We must have done something good. All we've done is increase the volume. The quality is still flaky. and we're still a very, very young industry. And I think it's to be regretted, the focus on doing. Once we figured things out, then we can focus on doing. But the industry tends to get things back to front.
Nune: Yeah, I I don't think computer engineering is ⁓ is developing as a science. It's defaul is developing a lot as something hands on. Isn't isn't that ⁓ why there is not a lot of emphasis on structuring things and ⁓ that's why we're doing it fast instead of right?
Barry: Yes, I think something, you know, something strange happened in our industry, where, you know, the typical idea within the sciences is that research happens and then based on that research, we have new discoveries and then we create industries. ⁓ In software, the industry is creating the narrative and research is chasing that narrative and sometimes chasing its own tail. ⁓ And it's an incredibly difficult... ⁓ industry to do research in because of the way software is. So a software project is what we would call ideographic. It's entirely independent. It has so many variables that you can't reasonably take two software projects and compare them because if you change any of the variables in terms of the people, and you don't understand the mechanism by which those people make the decisions, then you don't know what you're comparing. And it's very, very difficult to do reasonable empirical research within software. ⁓ And this leads to a kind of disconnect where, and the industry can very, very quickly decide, this idea sounds cool. We're all going to do it. And once the cool kids start doing it, ideas spread not through replication, not through scientific verification or validation. Ideas spread through charisma and gurus and people getting on stages and writing books through certain publishers that ripple through the industry. and can send us all like little lemmings running towards the edge of the cliff very, very quickly ⁓ with ideas that no one's really taking the time to step back and say, how would we prove that this worked? And if you work in pharma or in nuclear power or something, you have to slow down. You have to do the academic thing. You have to say, what way does this work? What are the consequences of this? And with software, you know, moving fast and breaking things, it appears, it feels inconsequential. And it's okay for lots of those little lemmings to run off the edge of the cliff. And most of us do it in the hope that, you know, you won't hit the ground, you'll hit a pile of already dead, quite soft, fellow lemmings. And that's what the industry is based on. And that's where we're at as an industry. But we will mature, one would hope, over time. ⁓ And our industry is only 90 years old. ⁓ And there's so much that could happen over the next few decades. Perhaps we'll start maturing, perhaps we'll start to take a step back and be a little bit more cautious. I mean, the current gen AI wave doesn't give us much hope that we've learned anything or grown up in any way at all. But you have to have some hope. for the future that there's going to be a difference here on this.
Nune: Hmm. Yeah, it's ⁓ I I'm gonna say something outrageous, but ⁓ the people who are let's say leading the industry, as you said, the people who are probably the loudest and the and the ones that are spreading the ideas are honestly not the people I want to be like. So usually you you read about the the prominent figures in your area and you're like, ⁓ I'm gonna I'm I wanna be this person, right? I wanna get there. But nowadays it's ⁓ more of a ⁓ my god, what are they doing? What are they even thinking? So it creates this disconnect and I maybe a lot of ⁓ bright minds wouldn't want to join computer science because they don't want to follow this path.
Barry: Yeah. Alan Kay mentioned a very long time ago, he said that something along the lines of that our industry is more akin to pop culture than it is to science. ⁓ And there are different rules to those games, to how you get an idea adopted scientifically and how you get an idea adopted in a pop culture ⁓ are very, different. Although I'm sure there are scientists. who would say that it's actually not that different, to be honest. I think that it's a branch that's very much in flux all the time ⁓ and people choose their tribes. And that is how the industry is moving forward. And I think as, if you want to take a scientific view of it, we can't entirely ignore that. ⁓ But the way that the hype machine, which I've seen several generations of big techs hype machine, I've been part of some of them. ⁓ And the way that they have ⁓ greased their wheels over the last 10 years and become so good at this, this marketing, this hype, this FOMO that they create over products that, if you know, controversially do absolutely nothing useful. ⁓ And that is not something that you want to be a part of. It's not something you want to emulate. Not if you're taking life, if you're taking your profession seriously, you know, just jumping on these bandwagons where there's no scientific evidence and there's nothing but insane projections into the future based on nothing that can make you take a step back and say, Hey, I don't want to be part of this fracas. It might be. it might be better to find a different direction.
Nune: ⁓ for for someone listening who is not in ⁓ as you said in an industry that i must slow down because of security, safety reasons. these people might think, Well, my industry is not that high stake, why do I need to take it seriously, apply scientific method, try to structure it? What would you would you say to them?
Barry: And I've definitely heard this argument that, I don't need to think about any of these things. I don't need to think about quality or security. I just build, you know, run of the mill, boring systems for small enterprises. And there's two angles to think about this. The one is the technical angles. First is that we are building software for business environments and we don't know the future of those business environments. We don't know. what direction our company is going to move in. We don't know if we're going to suddenly become successful and increase our customer range. We don't know if we're going to be bought up by another company. And we don't know what role quality is going to play in the future of the applications that we're building. Is it possible for us to say these kinds of things? It's one of the things that gets us into trouble as software engineers is thinking that we know the future of business environment. ⁓ And the quality will always play a role in what we do. ⁓ And there's an element of professional pride in that. It's to build a system of high quality is not a great deal more work on the day than to build a system with low quality. But it's a whole lot more work on the weekends and the evenings where you have to study and learn these things. And it's up to you whether you want to put that effort in or not. And ultimately that attitude ⁓ of, don't need to think about quality. I just build whatever solves the problem. That's going to show up in your paycheck in 10 years in a big, big way. And that's up to you. I like a bigger paycheck and I think a lot of us do. It's entirely up to you. If you don't want to care about your professional integrity or the quality with which you do your job, okay, the industry needs, there's maybe a hole for that. There's maybe a need for that in our industry. ⁓ But you know, good luck.
Nune: Yeah, I think with a paycheck argument you are appealing to a lot of people. So it's simply if you are after a a bigger paycheck, you have to learn how to think i outside of your domain, maybe outside of your concrete task at hand, but also understand how things are dependent on each other and and how the whole
Barry: That's tasty.
Nune: world works. I don't know how else to say it. And I think mathematics teach you z that, how how the world works and how to put it into components and and express that in a in a in a hands-on way.
Barry: Thank Yeah. And I think there's an excellent, I normally give ⁓ software engineers who want to become architects, I give them two books to read. And the reason I give them these two books is because I say, look, you've got to figure out who you are in this industry before you go any further and before someone else will come along and tell you who you are, if you don't decide for yourself. The first book is called How to Solve It by Giorgio Poglia. So Hungarian mathematician and this is a book that will appeal to all of us, right? It's about how to solve problems using logic, using mathematics, using critical thinking. It's an incredibly important book because critical thinking is one of the things we need to be good at. And for some people when they read this book, all the right parts of their brain light up and they get a warm fuzzy feeling and they think this is me, this is why I was put here, this is what I want to do. The second book I give them is the book that decides whether or not you're going to be an architect. So, how to solve it's for programmers. The next book is called Lateral Thinking by Edward de Bono. And it talks about how do you think outside of sort of these logical structures, which programmers love and programmers tend to get a little bit caught up in the logic and they tend to torture other people with it. and say things like, ⁓ but what you're saying doesn't logically follow and now you're wrong. And then we could turn up in a room, tell everyone that they're wrong and upset everyone. And then we leave the room going, why is everyone in such a bad mood? and De Bono's book tells you that, you know, the way to think outside of these rigid frames, which we're not good at as an ⁓ And the way to do that is to, first of all, to find dominant or polarizing ideas and question them.
Nune: Yeah.
Barry: and really question them and go hard on those dominant and polarizing ideas. And that would mean, for example, in today's industry, finding ideas like Gen AI is going to make us all jobless or it's going to solve all these problems or the agile method or patterns or any of these things that are accepted ideas. Attack them and use randomness and don't be afraid to stray off the path of logic as long as you come back to a logical conclusion. It's perfectly okay to ramble a bit. And this book, when programmers read this, your reaction to this book will decide whether or not you're cut out for a career in architecture. ⁓ If it's one of disgust, which it is for lot of programmers, how dare you say something that isn't demonstrably and logically true? ⁓ Then how dare you delay the conclusion, logic until the conclusion. And that tends to ⁓ tell us, are you going to be comfortable in the role of architect where you have to move outside of the code, outside of pure logic and deal with human systems. And those human systems do not have ⁓ logic or reason. can't be understood. They can't be structured in the same way that software can. ⁓ And so someone's reaction to de Bono's lateral thinking lets me know and should let them know, am I going to be comfortable in this world of architecture? and the, that questioning of dominant ideas is something that the industry really tries to stop. Just go out onto any social media platform and say something, not even negative, but just question a dominant idea and the hordes will descend upon the thread and tell you how dare you question this idea. This is established fact. It's far from established fact, right? It's a meme that got popular in like 96.
Nune: Ha ha ha
Barry: But it's ⁓ a problem that our industry has is letting go of these ideas. It's very, very easy to arrive in dogma when we don't have ⁓ scientific validation. Dogma replaces it and superstition and myth and questioning those things is probably the only way forward for architecture.
Nune: Hm. ⁓ w we're going completely off script here, but I can't help but ⁓ but ask you ⁓ do you think that part where we where where you said ⁓ in the architecture you need to be get comfortable with the uncomfortable, ⁓ do you think that's the creative part of the job versus the craft part of the job, which is the l algorithms, logical thinking, etcetera?
Barry: I
Nune: Or is there no place for sort of creativity? This is a science and we need to just be rigid and and all?
Barry: Yeah, I, I, so I really hate the cliche that, ⁓ you know, people say programming or architecture is, an art and a science, Because to me, that's just more fluff. it's, ⁓ I think that it's, what I'm saying is that, that we need to have this rigid critical thinking, logical thinking, right? You cannot work with code without that. is, it's, it's impossible. ⁓ But when it comes to the business context, the area around the software, the people and the markets and the competitors and all of that stuff, rigid logical thinking will just get you hurt because you'll try to reduce those environments to something, you're reducing things that can't be reduced. ⁓ And when you reduce things, you miss things. And when you miss things, your software breaks. And that's the history of our industry, more or less. ⁓ and so to the rigid thinker, the person who's able to abandon logic and work with the content, the business context, the complex as it is, and is able to roll with the punches, it's able to anticipate some of the things that might change without entirely knowing why, ⁓ to able to use a mixture of speculation and common sense. ⁓ figure out where this system might move, which becomes instinct, as you said, gut feeling in almost all senior architects, to the rigid logical thinker. That appears like magic. appears like creativity is just a word we put on it. ⁓ And so part of what I've been trying to do is say, what is this creativity? What is this thing that allows me and other senior architects to cope? with this complex context, but some people, especially the more rigid thinkers among us, tended to collapse at this point and can't cope with it. And we call it creativity. ⁓ And it is creative and you'll find that they're very, very, very creative people. They're imaginative and usually fun people who can do this. But there's something else going on. ⁓ Creativity is a very loose word. to describe what we see. And it doesn't help us to teach architects, because that's been my major mission in all of this. How do I teach architects? How do I teach the next generation of architects? And make them creative is not useful advice because nobody actually knows how to do that. And so we need something else. We need to go beyond this art and science. idea of software engineering and saying what do we mean by art? What is it that makes us successful at this? ⁓ know, firing a trebuchet ⁓ at a village was ⁓ an art until Isaac Newton came along and said actually you know there's something else going on here so we don't need to be creative anymore because now we can calculate it.
Nune: Yeah. Mm-hmm. ⁓ so I I think that's exactly ⁓ ⁓ the residuality theory helps is put this magic into structure. ⁓ ⁓ let me give you my understanding of it and and we go along from it. So the main idea is that ⁓ we take a system ⁓ under the system we understand interconnected components.
Barry: Yep.
Nune: And we stress them, we poke them, we put them into weird situations. and one of the basis of what you're saying is that then this will settle into a stable configuration. and I imagine it ⁓ a as if we take some marbles that are connected, some with ⁓ s strong wire, some with loose wire. and we put them on a plane of hills and valleys and we blow on it, we poke it, we ⁓ put some pressure on it, they will eventually settle ⁓ into some configuration. Is that somewhat accurate?
Barry: Thank It is, yes, yes, I think. So the basic, the very, very basic idea behind residuality theory says that a random simulation of stress, as we just make a bunch of stuff up about what might happen in the environment outside of what we already understand, produces an architecture which, for a reason we haven't explained and don't understand yet, is more likely to survive unexpected changes in the environment, what we call unknown unknowns, which is the curse of software architecture has been since Dijkstra's time when he was writing in the 1960s. When we build software, the environment changes and the software breaks. It's expensive to change. That's only problem that we have in software. All problems can be reduced to that. ⁓ And software design and architecture exists to counter this problem. as the suggestion in the 1960s was that modularity would eventually be seen to be the solution to this problem. That's all that's that's all it is. A random simulation of stress will lead to an architecture that is more likely to survive off spec. And that is was, if we go back 12 years, was a curiosity. It was when I sat down and said, how do I do architecture? What is it that I do? What am I doing that other architects aren't doing? And how can I turn this into something that I can teach? What I discovered about my own practice was that I was just randomly stressed, just making stuff up and stressing the architecture and just trying to get it to break in as many places as possible. And as those cracks and splinters appeared in my architecture, ⁓ then I started to realize the properties of the architecture, where it broke, where it cracked, what I could do to stop it breaking and cracking and control the way it fell apart. I realized that eventually once I had control over the way this thing fell apart, that the architecture would start to survive things that weren't in its specification. And once I seen evidence of that, then I would say, now I'm done and I'll move on from here. And I realized that this Uh, this description that I just gave you that described what I had previously been saying. This is a gut feeling, but it never really investigated what I was doing. And when I compared what I was doing to what I was taught to do, which was all about structure and requirements and risks and writing things down and going as far as fancy little sigmoid curves to balance trade-offs, pretending to do math, um, to try and make it seem rigorous. What I was doing was the exact opposite of that. I'd thrown all of this stuff away. said, I'm just going to make stuff up until this thing stands up on its own. More like Bambi than a structured, Bambi on the ice figuring out how to stand up, rather than some structured engineering effort, which we had all been taught was the right way to do things, even if our teachers couldn't tell us exactly the right way to do things.
Nune: Yeah.
Barry: And that ⁓ became, eventually became residuality theory where we started to look at why does this work? And the why behind that goes closer to your marbles analogy where it actually turns out that there's a bunch of properties of complex systems that make it inevitable that we will do this, that this will work if our stressing of the system is broad enough and isn't restricted by things like risk management and that kind of probabilistic thinking, or that need to be correct that comes from the rigid thinking of the origins of our industry. ⁓ And that then has led to the concept of residuality theory. And then it turns out that it's the easiest thing in the world to say a random simulation of stress will produce the right kind of architecture. But if you take someone who's been trained in traditional engineering methods, traditional programming, and tell them to produce a random simulation of stress from the business environment, they fall apart. None of this makes any sense to them because they've been taught to think in a completely different way. And so I had to create a scaffold, which is the concept of the residue and some ideas that I pulled from the complexity science in order to guide them through this process to make sure that the stressing became random enough to actually give a result.
Nune: So if the point is that i if we know for sure that the the components will fall into a s certain state, so the goal is to find one of those states ⁓ and component connections that will survive as many of those stresses as possible.
Barry: Yes, ⁓ yes exactly.
Nune: practically, how do I start? ⁓ I'm given a problem, how do I even start solving it?
Barry: Yeah. you, so the first thing you do is you solve it. So you're an architect. You've been around for a while. You know how code works. You know what a component is hopefully. And someone says, we need to solve this business problem. And you'll immediately in your head, you'll start in visit, in visiting. what is this? Is it a bunch of, is it a bunch of lambdas? Do I need databases to any queues and you'll have a sort of vision in your head. What, should I solve this problem? And the first thing you do is you draw that and you say, this is my naive architecture. It's based on my naive understanding of this business environment. And then what you want to do is you, then take a step back from that and say, right, if we put this in production, what would stress the system? What would happen that's outside of the, I currently, I have a model of how this works in my head. I have a model of the, market. I have a model of the competitors. Maybe I haven't thought about that yet. I have a model of what we have to do for most software engineers. The model is entirely functional. What does this system have to do? What does it have to achieve in technical terms? And then you start to stress it and you say things like, what if I'm wrong about this? What's going to move and shift in this? What if we don't sell as much of this thing as we think we're going to? What if we sell 10 times more than we think we're going to? Where does the architecture break? And if it breaks, is that a surprise to me that it breaks in this way? Is it a big problem for me? Do I have to rebuild the architecture? Do I have to restructure this if it breaks in this way? Or is there a way I can structure the current naive architecture? Is there something I change to make sure that when it arrives in this place that it won't completely collapse, it will continue running. And you might ask questions like what happens if a competitor drops their price? Or what happens if there's a drop in the exchange rate between the Euro and the dollar? Or what happens if we block the strait of Hormuz? ⁓ happens if, you know, and these things ⁓ are, you we're kind of tainted by ⁓ risk the way we've been taught to think, or scenario all these tools we've had for years. And they tell us implicitly that we only talk about things that we believe are likely to happen. ⁓ And if the software industry has taught us anything, our difficulties in coping with change in software tell us that the things that are going to hurt us are things that we don't believe are going to happen. The things that we don't believe in are the things that cause us immeasurable amounts of pain because they turn up anyway. And so what we try to do is we try to make that as broad as possible as spread of stress. And it really doesn't matter. what the stressors are or if they're realistic. We just need to get to the point where we say if this particular situation should arise, the architecture will fall apart in this particular way. And one of the things that I had to do, one of the things I realized was that by using this methodology, I was actually implicitly saying that an architecture always has more than one future. And when we are in a business environment, there are so many things that can happen. And the architecture must be built to cope with those things that can happen, those multiple parallel futures. And so I came up with this concept of the residue. A residue is what's left over when something gets hit or gets stressed in some way. And by talking about my architecture, as multiple parallel residues. what I was doing was I was forcing myself to think about the architecture in multiple parallel possible futures, ⁓ which is something that's ⁓ not a default way of thinking in traditional engineering methods. We tend to try and reduce the model of the system into a future which we understand and predict and control. That's why we put probabilities and impacts on things. Whereas this explicitly says there are multiple possible futures, we don't know which ones are going to occur. What's the right architecture for an environment with these multiple possible futures? And it turns out that through some mechanisms of complex systems, that when you do this and you find the fault lines in your architecture, you'll find that that architecture solves the problems over and over over again, perhaps without knowing what those problems were, which is... the thing that makes the theory interesting.
Nune: Yeah, so when you solve it for one even impossible ⁓ or or less probable stress, it suddenly turns out that there were n amount of other stressors that the same architecture would have survived. So it made sense to do this exercise of stressing it with low probability of things.
Barry: Yes. So this comes from a result in the 1960s that showed that ⁓ complex systems tend to arrive back in a very, very limited number of states ⁓ out of their potential phase space. So every complex system has enormous amounts of potential states. ⁓ And what we see in the real world is that most complex systems are trapped within a very small number of those states. And by cont, and therefore every state that a system can arrive in, it actually maps to a large number of these stressors, these events that we don't expect. And by getting a broad enough sample of those stressors, we discover these particular attractor states that the system is going to arrive in and build an architecture for those attractor states. And that becomes our parallel architectures. And it turns out that that solves an enormous amount of the... problems that we see in software architecture. And you can measure this. you read my work, you can measure this. You can see that you've had this effect on your architecture that it becomes observably more likely to survive on known forms of stress ⁓ simply by stressing the architecture to a particular state. This goes against the industry literature, which says that you sit down at start of a project and you decide what your modules are going to be and you make them loosely coupled, whatever that means, and you make them cohesive, whatever that means. ⁓ and that will lead to a good architecture. And those ideas come from studying successful systems. And when you look at a successful system, you'll discover that it is modular and loosely coupled and cohesive. ⁓ But that doesn't mean that modularity and loose coupling and cohesion always create a successful system. And so the conclusion I arrived at is that successful systems have these properties. And that stress actually drives the system to a certain degree of modularity, a certain degree of loose coupling, a certain degree of cohesion. And the first place I found that agreed with these ideas was of course, Nassim Taleb's anti-fragile, which says exactly the same thing, that complex systems that survive for a long period of time are not designed by human minds. They are created through constant application of stress and survival against that stress. And the result of that is a modularity with a coupling and a cohesion.
Nune: Yeah, so I I think a a lot of the times we build safety mechanisms into architectures to ⁓ say in in our heads say well when this unlikely or likely problem happens, I hope this safety mechanism that I put into it, be that as you said, loosely coupled or layers ⁓ between components contracts ⁓ them that we hope that when this problem arrives these safety will help us. Th that was the the modus operandi but that's not what you are saying, right?
Barry: Let's. Well, I think that it's the same idea. So if I come along and I say that, you know, I'm going to split this into two modules, I'm going to put an interface between them, I'm going to protect them from each other. I'm going to, you know, use Parnas' thinking and hide their internals from each other. Those things will protect you against certain kinds of stress. And when an architect does that, they're thinking about those particular kinds of stress. They're thinking about what if this thing changes? I don't want to have to change both these modules. ⁓ If this thing changes, I want to contain that change inside this particular module. So that thinking has always been there. ⁓ And ultimately the conclusion I arrive at when I boil everything down is that all architecture that we've ever done, all architecture is stress. We're taking a particular structure and we're saying, is this going to break? How can I protect myself? against this particular breakage. But the engineering tools that we've inherited, the way that we look at the business context, the way we reduce it, the way we try to find probabilities and impacts on what risk management teaches us to do, actually restrict the number of stressors that we can throw at our architecture, which means that the input to our architecture is very, very limited. It's the same with requirements, right? With requirements, we're trying to take the possible field of everything that can happen. and crush it down to the smallest possible field so that we can write code that we know will be correct against that specification. And we ask people, what are your requirements? What is the future of this business system? And they don't know what the future of that business system is. And we don't know what the future of that business system is. What we're saying is, would you please guess so we can have a specification and we'll be correct against the specification, which is only a guess. And we know it'll blow up in the future and you'll pay it. You'll have to pay us to do it again, because it'll be your fault because your guess was wrong. And that gave us a very lucrative business model for several decades. But there is a different way of doing this. And that is by getting rid of these engineering tools, things like risk management, which is the problem. And then we can have a broader selection of stress and that leads to more stable architectures. And this is, it's a controversial statement to say that, right? Because, because we're going against 40, 50 years of software engineering thinking where we try to reduce the business context to something we can control and understand and be clear and certain about. And then apply a couple of patterns, which will make us loosely coupled and modular and hope that that solves the problem. But those are, you know, kind of, they're... we get cause and effect confused when we make these decisions. And whenever I discovered this, I realized what I'm saying is deeply controversial because I'm going against everything that we've been taught when I say this. But as I talk to more more senior architects, people who had built really big stuff, they said, yeah, you know, now that you describe it like this, this is also what we do. And I realized that what senior architects were figuring out across a decade or more of suffering in their own careers was that randomized stress produces very, very strong architectures. And so what we're doing is we're learning one thing and we're preaching one thing, right? Because we're still telling junior architects to read this and read that and read, you know, Constantine and Jordan and modularity and all of these things. But we're doing completely different things. where the gut feeling that we ascribe to our work, when you dissect it and look at it is pure stress and it's randomized stress to make that as broad as possible. ⁓ And that's fascinating. And that's why that's when I decided this, it's not going to be enough for me to write a book about this. have to go and prove that this is true. And that's why I went back to university and started the PhD program. I started working towards designing an experiment so that this could be scientifically proven and gathering data. to show that this actually works all the time.
Nune: Hmm. If we go back to like a bit of a practical ⁓ advice or approaches, now that I let's say have my naive architecture, how is it different from saying, well, I'll go and gather non functional and functional requirements ⁓ and then apply it to my architecture? Is it similar? Is it is it merely that you're saying that ⁓ doing this has is a proven path or is it more than saying let's gather all the non functional and functional requirements?
Barry: Well, I would say that we've had several decades of gathering functional and non-functional requirements and talking about things in terms of these. And we have this lovely thing called the Standish Chaos Report, which has been a little bit criticized for its methodology, but it's still, all we've got. And it shows that the needle hasn't moved. We're not really getting any better at building software. So these approaches, these ideas are not working. ⁓ The division of software into functional and non-functional requirements is something that makes me very sad ⁓ because ⁓ the fact that we call them non-functional requirements is ridiculous because the requirement is what do you want the system to do? And that's a reasonable question. And it's been shown over time and the agile movement diagnosed this perfectly that when you ask people, what do you want the system to do? You can't trust what they say. because it's going to change, it's going to move with time. And a non-functional requirement, when we call it a non-functional, I use the word non-functional aspect, right? So a system has a bunch of aspects and it has a bunch of behaviors, right? Around security and around scaling and availability and all of those things. Those are not requirements, okay? Those are behaviors of the system. And those behaviors of the system arise in conjunction with the... the state of the business context. Okay. So the availability that you need or the scale that you need is a function of what happens in the business environment. And as we've already said, most people don't, we don't know what's going to happen in the future of a business environment. So a non-functional requirement, when we make it a requirement that someone has to make a statement about what availability do we need? What security do we need? What, what performance do we need? Those are mostly guesses. and they're not. really requirements. So if you take a business person and say, what are your scalability requirements? They just, they just don't want to talk to you anymore. Nobody knows the answer to that question. And so the traditional methods of gathering these requirements as a specification and saying, this is what the future is going to look like, build the future, gets us into trouble over and over and over and over again. Whereas the stress, and all of those things have to be likely, right? They have to be real and you'll get people saying you ain't going to need it. You know, keep it simple, just build what we need today and then we'll iterate on it tomorrow. With the, what I'm saying is that, no, that should be randomized. Stop looking for the right answer. Stop trying to say what is the availability requirement for this solution and say that this solution is going to have a varying degree of, of load or downtime over its lifetime. How do we build an architecture to cope with that varying degree? And what would it look like to build an architecture? that isn't locked down to a particular availability. How do we get out of all of these holes if we arrive in them? If we should have an availability that is much less or much more important than what we thought it was, how would we change the system to move with that? And this is a very different way of the specification way of building software, trying to figure out what should that exactly should this thing do. in order to efficiently build a system that will only do what we need it to do and nothing else, which is a kind of factory way of thinking that we've carried with us into our industry and has stuck around.
Nune: I think that also reduces a lot of stress ⁓ from both sides if if we say business and and software because now we're not harassing business people with tell me what are the requirements. Instead we are exploring this domain and exploring the realm of possibilities that they think might happen and and and by doing so preparing the architecture for also the realm of things that nobody knows will come, but they will come.
Barry: Yes.
Nune: And and I think I I have been thinking of non functional versus functional requirements in a way ⁓ that would be applicable to say it's ⁓ technical stressors versus business stressors and and and those probably your peers ⁓ and the architect themselves are better equipped to ⁓ generate those technical stressors. What if a data center goes down? And the business people are more equipped to explain to you all the kinds of ⁓ business stressors or functional stressors that can happen. The one thing that I think might the might architects not want to do is actually dig into the domain and and say, well, what ⁓ am I supposed to be a domain expert now and understand all kinds of stressors and understand the industry I'm in?
Barry: Thank you.
Nune: Am I just the person who creates models?
Barry: Yeah, I would say that yes, you do have to become the domain expert. If you want to be an architect who is any good at this job, you have to get into the domain. You have to understand what happens in the domain. And the first part of that is understanding that domains, business domains are complex, truly complex systems. You're not going to be able to... draw a nice little neat diagram that explains exactly how it happens. And every time you draw a nice little neat diagram in order to try and understand it, then that diagram is going to blow up when reality hits it because it won't capture everything. And once we've understood that dynamic, then what we tend to find is that you have this, so you have this software architecture, which is, which is a structured mechanical system. It's ordered, easy to understand, clear rules between cause and effect. ⁓ And then you have this complex business system around it. And once you start thinking about it like that, which residuality kind of forces you to do, because it's at the core of residuality is this idea of the structured software and the unstructured environment. The architect's job becomes managing the relationship between that structure and that lack of structure, that constant flux. does it do to the structure? And this causes us as architects. forces us to think about the functional and the non-functional at the same time, which is what we should have been doing all along, not separating them into two separate things where one gets treated by enterprise architects with a checklist and the other gets treated with user stories and separating things out like this, which hasn't really done us any good at all because these functional and non-functional things have to live together in the same system all the time. so I think that one of the things that comes out of applying residuality theory is that architects are forced from day one of their work to think about non-functional requirements and not sweep them under the rug or have them as the last chapter in your requirements book because there has been through the history of our industry a focus on the functional before the non-functional especially when it comes to this move fast and break things thing. Non-functional requirements are the things that break most of the time and the things that will sink your project most of the time.
Nune: ⁓ I think ⁓ some people who are listening to this will say, Well, I'm not in an big enterprise setting, I don't need this. Does this theory n or this way of thinking n need to have an enterprise big setting to be valid or can I apply it to my simple to do list application? and to my startup, which is ⁓ a v very much more unstable, unknown. ⁓ I don't even have probably the domain knowledge of a startup ⁓ yet alone ⁓ be able to explain it to myself, ⁓ in this case if I'm both founder and the architect.
Barry: Yeah, so there are incredibly simple systems out there. And you'll find that most of them are embedded systems. Not that that work is simple, but the system itself is simple. The system is constrained and it has to do a very particular thing. And it's constrained by the chips that have been designed. You've got to write some software that makes it do this and makes it do that. And there won't be a great deal of stress heading that system because it's isolated from its environment on purpose. And what you'll find is that these ideas wouldn't give you a lot of benefit in that kind of scenario. It's really what you put a whole bunch of those things together to create a bigger system that you'll start to find that the human environment starts to affect the way that the system is going to evolve over time. And that's when you need to start using it. Now I would tend to use these ideas on all projects for two reasons. One is that sometimes, lots of times, When we as software engineers look at a business problem and think, this is a simple problem. I don't need to think about this at all. I've been told the truth. I know the future of this system. We get caught out by that so many times and then something changes and the whole stack collapses. You have to rebuild your architecture. So it's safer from my perspective to use these ideas and verify that you, you actually, this is a simple system because if you try to use residuality in the system, simple system, you'll run out of steam very quickly. You won't be able to stress it. You won't be able to push it around. And using these ideas will confirm to you that this, yes, this is the right way to go. This is just a simple system. Then you can move forward in the safety of that knowledge. And I would say that... every architect, no matter what kind of system you're building. Unless you're writing a single procedural file using GoTos, because this is so simple, it's never going to change. I can just write this code, I can write it in ALGOL and it will work perfectly. I don't need to think about it. Nothing's going to change. This is as simple as possible. It's going to be one executable and a little script somewhere. ⁓ If you're doing more than that, if you're breaking your system into modules, if you're making decisions about coupling, if you're adding cues to your solution, then you are on by default, you're looking at the business environment, you're saying this thing might change. And I'm going to solve that change by adding this little thing here. You're already thinking in parallel timelines. You're already thinking in residues. But. you're using the narrative of the traditional engineering paradigm that we imported into software in the sixties. That tells you, I'm doing engineering. I'm doing everything according to a specification, but you're not. You're making up your own specification by stressing the thing. Because there's no one's going to tell you where to make those module breaks, where to make those interfaces, how loosely or tightly coupled they should be, what cohesion is, is all entirely inside your head. And this is the big struggle with software architecture. Because a junior architect won't know what to do. They won't know how to make those decisions. And there's all these books saying, ⁓ you find all the verbs and then you find all the nouns or you do this and you do that. But the truth is that we stress, we look for change, we look for elements of change and we stress our systems. And we've known this for a very long time. So I would say that everyone who's doing any kind of software architecture is already using the ideas in residuality, but they just don't have the language to describe it. And what I find from teaching this to thousands of architects across the world over the last 10 years is that most senior architects will come to me at the end of a course or the end of a lecture and say, this is what I've always done. This is what I do. I stress. I think that because your podcast is called Root Cause, so at the very roots of architectural thinking is this concept of stress. Everything that we do is taking an idea, which we know we understand poorly and stressing that idea. until the architecture becomes stronger. And residuality is just a formal way of describing that stress and allowing us to measure, being explicit about what we're doing, because we haven't done that so far, and then being able to measure what it is that we've actually done at the end of a stressing effort. So I would say that you're doing it anyway, you might as well learn this formal language of doing it. And the people who are doing it but don't understand it,
Nune: Mm.
Barry: They describe their work in terms of requirements or non-functionals or object orientation or patterns or agile, if some other way of describing ⁓ the way that they do their work and one of those narratives they've inherited from the industry. at the root of everything architecture is stress.
Nune: Yeah, and I I think I've seen ⁓ two camps of people who are somewhat ⁓ negatively ⁓ reacting to your posts. i one camp is if they have been very much into a specific theory before that and as you said that this is a ⁓ a culture of of of following a certain idea and they get agitated.
Barry: and
Nune: And the second camp of people ⁓ who might not ⁓ answer positively is is these people who say, Well, we've been doing this all along. A and I think yes, we have been doing this all along, but the inability to put it into words and in a inability to also have proof that you have built a more strong system. ⁓ that has been lacking and this is what you are addressing. So I think everybody needs to calm down. This is not a revolution. I mean you still need to be a good architect, as you said, right? You still need to understand, I don't know, OOP microservices, ⁓ how how infrastructure works. This is this is not going anywhere.
Barry: Yeah. Yes. No, we still, you need that base level of knowledge. What is software? How does it work? What happens when you split a boundary? What different ways can you split a component? What different ways can you deal with latency problems or drop messages or any of these things? We need to have that deep, deep technical knowledge. But you also need to stretch out into the business environment to find that stress because stress isn't this generic thing that hops around from project to project. It's context specific and you need to uncover it as you work. I think there are many people who like to believe that we've already solved everything. We already have our little toolbox of ideas that definitely absolutely work. And I have this thing in both my books, it's called the walking theory of architecture. And it says that we solve problems by just walking around the problem very many times and stressing the solution that we have through those walks. And those walks can be anything. They can be risk management. They can be scenario analysis, all of these things that I've, you know, I've dissed during the last hour. But they, doesn't matter because it's the cumulative effect of stressing that eventually produces a good architecture as we walk around and around and around the problem. And so a lot of senior architects will figure this out and they'll figure out that I need more walks. so. Once they figure that out, then they'll look at their little toolbox and they'll assume that this is the right way to do architecture. But they have no explanation for the fact that there's a thousand other architects who have completely different toolboxes, use completely different methods, but get the same results. And they're all successful. And the thing that unites them all is this walking with these tools and using these tools to explain their success. But at the root of all of that is stress. And there are people who feel threatened by the, by the new idea. ⁓ And there are people who, who, who like the comfort of the idea of the, of the world that they're stuck in. And that's okay. That's fine as well, you know. But at the end of the day, and what I'll say to those people is do you have empirical proof, evidence that this works? Because I do. And, you know, and that puts a, puts a sort of spanner in the works. of their argument and eventually it'll boil down to, yes, but I've always done this anyway. I say, that's great. That's what I'm saying. But did you write it down? And it turns out, no, I never wrote it down, but I didn't say it to Diev in the pub in 1998. It's like, you that doesn't, that's not how science works. Right. You have to write an idea down.
Nune: Yeah, ⁓ f finally we we don't need to keep all these mm possibilities of architectures in our head. We have a word for it, ⁓ and and we can put it ⁓ on paper, review it, ⁓ and then actually how how often do you ⁓ do do you write all of these scenarios down? How often do you come back to them and
Barry: Hmm? Yeah.
Nune: Consequently, also, if you're saying that ⁓ by these stressor effects you can build a perfect architecture, how recurring is the role of an architect? ⁓ is it that means you know I come, I it enough times, I build the architecture and then I leave, or is it and am I this ⁓ s this residues? Afterwards.
Barry: Yeah, so there is no perfect architecture. That's one thing that we have to, residuality will not help you build a perfect architecture. The only thing it does is it helps to build a critical architecture and critical means it has a property of criticality. That means that it is more likely than your naive architecture to survive unknown, off spec events. And that's the best we can do. There's no architecture that's bulletproof. All architectures that we build ever are going to die. ⁓ And all we're doing is pushing that date of death out into the future. with these methods and these ideas. That's the best that we can actually do within the confines of our understanding of complex systems. So what I tend to do then is I'll come in, stress, then we get our base architecture and we're quite happy with it. But architecture never stops. The system, the business context keeps moving, the technology platforms keep changing. We have to constantly be there. And so Whenever something changes, you record everything in something called a stressor analysis. It's all done in Excel. We don't need fancy tools. And you go through your, you go back through the stressor analysis. Every time something changes and you add a new thing, say, is something else going to cause hiccups here? It's a combination of different stressors combined with this new thing that we're doing going to cause us issues. And so you're constantly reusing it. And as you live with the project over a longer period of time, you'll start to see more and more of these phase states, these attractor states that the business system arrives in, and you'll be able to update your architecture and change it over time. So in this view of architecture, it never stops. It's always happening. ⁓ And it's not something that should sit in the head of one person, but it's something that should be spread out through the team. The entire team should be aware that architecture is stress. And they should know how to stress and developers should be aware of why am I writing this particular function this particular way? What stress is driving me to have to do this rather than I just write functions or I just write against the spec which someone, which falls out of the sky at some point. And so architecture becomes in this way of looking at things much more decentralized, but still centralized to the people who can do it.
Nune: I think it's the ⁓ shared ⁓ language ⁓ th that both business, software engineers, architects, they can share ⁓ a sort of a blueprint of their direction. Yeah.
Barry: Yes. Yeah. And I think that the nice thing about the shared language is that it works for everything that we have to do. So if you look at traditional architecture, you've got to do your component breakdown, you've got to do your requirements engineering, you've got to do risk analysis, you've got to do process analysis, you've got to do a security analysis, you've got to do a performance analysis, residuality boils up, says you're not going to silo this job up into lots of neat little blocks, you're going to have to do everything all at once while everything's changing. all the time. And that's a much harder question to answer. None of the tools answer those questions. And the tools are far too siloed and far too specific. And there's a fantastic book from 1981 called The Reflective Practitioner by Donald Shun. And it talks about how people who work in complex environments ⁓ have this description of how their job is done. And he calls that description technical rationality. It says you do A and then you do B and then you do C and then you go home. ⁓ And he says that this is what they're taught. This is what they use to talk about their work. But in reality, they do something completely different, which he calls reflective practice. They try to apply the original theoretical ideas. They don't work over time. They adjust constantly how they practice. ⁓ And they end up with something called reflective practice. And when you go to them after many years of reflective practice and say, how do you... do this, they'll say exactly what I said when I was approached. I have no idea how I do this. I know that I'm right, but I have no idea how I arrive at these ideas. And that is what's happening. Residuality is taking that reflective practice of architecture and saying, the technical rationality, the risk management, the requirements engineering, all of this stuff that we say we do, that's not real. That's just some sort of scaffolding or story we tell juniors or tell ourselves to try and pretend that we're engineers. But what's actually happening, the reflective practice is residual, it's stressing. So I'm trying to get to the bottom of what is it that we actually do, not how do we describe our work or how have we historically described our work.
Nune: ⁓ one thing that you mentioned is that we build ⁓ good architectures because it's expensive not to have one. ⁓ when it falls apart you have to rewrite it and that is expensive. And I think a lot of people who nowadays use AI for coding, they would now say, Well it's not expensive anymore. We can rewrite software ⁓ by just ⁓ writing a prompt. not by just writing a prompt, but by creating these agentic systems that constantly write and rewrite and ⁓ create code on the fly. ⁓ do you think AI generation in in that terms of making purely code writing cheaper has affected architecture? I would guess you'd say it's made it even more important, but go ahead and say it. ⁓
Barry: Yeah. So, so the first, the first thing I would have to do, is, is to question the assumption that software writing software has gotten cheaper. So software is a huge chunk, writing software and maintaining software is a huge chunk of the budget of most companies, between three and seven percent of a large company. If that had gotten cheaper, we would see margins rising at those companies. We would see IT costs falling. We're not seeing that. And we would also see more software being produced and we are seeing more lines of code produced. But that's because of the idiocy of measuring lines of code and calling that software. Software is stuff that works and runs in production, not lines of code. Lines of code are just lines of code. And we've had compilers and we've had code generators for a very long time. So we could have generated any number of lines of code we wanted. And now we are using these prompts, which are using statistical inference to decide what the right line of code might be. And there is a vision of the future where we tell it what we want and it produces exactly what we want with high level of quality. Now that future has not been realized. are telling it what we want is producing a bunch of crap, which we have to sift through, which we have to fix, which we have to tweak. we need that knowledge of the senior engineer to be able to do that. We're going to have to shift it. We're going to have to move the code around. It doesn't seem to be able to reason about modular structure or it can only do what it's seen before. And so I don't believe that code is getting particularly cheaper. I think that if you're an architect, you're going to have to prepare yourself for a world where people are just going to throw slop at problems and your job is going to be managing that slop. Although one would hope that this little fias will die out over time. But we're starting to see, now you've seen this on social media. In the last week, we're starting to see that the hype dying down from where it was six months ago, and people saying, actually, you can't simply prompt your way to an application. know, when SAP aren't going to fire all of their developers and say, the next version of SAP is just a single prompt that says, build me an enterprise resource planning system. That's not going to happen. Real engineering is still necessary. Thinking about and understanding architecture is still going to be necessary. ⁓ I don't think we should make predictions about the future because nobody knows what's going to happen or where this thing is going to go. ⁓ But I am deeply skeptical to the claims ⁓ that people are making about these kind of things because one of the unfortunate things about studying a PhD is that you're forced to go and learn statistics. And if you've got a basic grasp of statistics and algorithms, then you can look at these transformer architectures and you can say there's no way on earth that that is going to ever. generate an architecture based off a natural language prompt. And there are arguments around productivity, and I'm hearing different figures from different reports. I tend to believe the lower end of the scale, not the breathless we're getting. I've had people tell me we had 720x productivity on this project. I've had someone seriously make that case. But I'm also hearing... on the grapevine that what we're actually seeing is two to three percent productivity increases. I think that all of those methodologies are flaky and but the hard questions are starting to be asked. if code is going to end at the end of the day, if you're working as an architect and you're using these ideas and you're thinking about code structure and inside the structure of the code. which you've decided as the architect, you shouldn't really care who generates the code, right? It doesn't have, if it's a machine or a person, it really doesn't matter to me. If they can make the machines do it more efficiently than people at some point, then that's perfectly acceptable as an architect. But I don't see LLMs as being something that can produce architecture. And, but what I think is if we're going to just, if, and if we should land on this as being the new way of developing software that you give a prompt to some machine and it spews out a load of code that functionally solves the problem. More and more people are going to want to take responsibility for the structure of that code because architecture is going to become this bottleneck. And if people are going to. start diving into why does code have a certain structure, then I think that residuality will help them to understand that the answers that were arrived at in the late 1960s and early 1970s are not the right answers for modern software engineering and residuality will help them understand what's actually happening there.
Nune: ⁓ I don't think ⁓ I think the idea of vibe coding is somewhat dead now. I don't think people expect now to or or at least not everybody expects to write a prompt and and get a code back. But now the tendency is to write these ⁓ little agents that do different parts of the job. One is ⁓ developing the code, another is developing the tests, the other one is reviewing all of that, and the hope again is that those agents will eventually by testing each other and and and ⁓ following ⁓ i their own strategy of working come to a working system. And and this brings me to maybe as you have said ⁓ We as developers, we have been thinking in very precise and logical structures. And business is not precise and logical. So business changes all the time. And one could say, well, look, LMs are non-deterministic. They generate this different versions of of s something that you requested. Why don't we use it to generate stressors and ⁓ why don't we teach it residuality theory, one agent who goes and takes your naive architecture, generates stressors, moves components around and comes up with a new strong architecture.
Barry: Yeah, so I mean, I mean that potentially could be done. But the thing that would worry me about that is if we go back to the, we talked about creativity and lateral thinking, the residuality always has to be done with regards to the context. And we're constantly trying to say with residual, when we ask a question about a stressor, we're saying, look, I have this model of the environment. What is there that's outside this model that might cause it to break? and then caused my software architecture to fall apart. And although we, although we use the word non-deterministic to describe LLM, so we're using a computer science term when we say that. So deterministic algorithmic determinism is when you get the same answer over and over and over again. But determinism in philosophy is something slightly different. And so a, an LLM is determined, it's determined by its training set. It can't act outside of its training set. can't do that. because it's bounded by it, it's bounded by those weights ⁓ in its embedding and it will never do anything outside of that. It does not have that human capacity to do what De Bono says and question the dominant idea, jump outside it and use speculation and imagination to do that and so it can't move with the context. It can only look back in time and say What's the average result of what other people said when they talked about this? And another way of saying what's the average result of what people said when they talked about this is the concept of patterns. And we've already tried this in the software industry, right? We had this mad thing in the night. said patterns are going to solve everything. It's just you solve something once, we'll re-solve it. Object orientation is going to kick in. We're going to have these patterns and everyone will just build software the same way we build Lego. It's going to be so easy and so perfect. And here we are in 2026 going, ⁓ no, this is object oriented code that I have to work with today. It's going to be a mess. And we've abandoned most of the big ideas like polymorphism and inheritance are no longer really mainstream tools used by software engineers. And so the idea of what we're talking about when we talk about LLMs being able to do this thing is basically restating the case for patterns, except now we're saying... Instead of patterns being something that ⁓ someone like Gregor or Martin goes out and writes a book about things they've observed in the industry and say, this thing turns up again and again and again. Now we're finding the patterns through statistical analysis. And we're saying that we can have many, many, many more patterns and you can look up those patterns through a search because they're indexed in an LLM. And we're saying that every system is just a bunch of old systems and pieces of old systems all glued together with sticky tape. And that's really not what residuality is saying at all. It's saying that this thing is constantly in flux and the kind of system you need will evolve out of being exposed to that flux and to that stress. The idea that a statistical answer to the question of my particular system and its particular unique business environment is held in a statistical analysis, a poor statistical analysis of the past based on text on the internet from projects that had nothing to do with this. is for me scientifically far-fetched. ⁓ And maybe I'll have to eat my hat, maybe they'll show that they can do this, but from where I'm sitting right now, it does not sound plausible. ⁓ so, I mean, residuality doesn't sound plausible. So what did I do? I went back to a university and did an actual scientific experiment, right? I didn't write a breathless article in Business Insider about how the world's gonna fall apart, how it's gonna change everything. That's not what scientists do. If you believe that you can produce architecture from statistical inference based on a bunch of text you scraped off the internet and created a model from, fine, show us. Show us scientifically. Not an anecdote, not some person in Silicon Valley saying, ⁓ we're cooked. No, I want to see science. And until I see science, everything is suspect. This is probably bullshit. It goes in that bucket.
Nune: ⁓ yeah, also ⁓ I think and and I'm reflecting about this a lot lately, ⁓ is how this whole process of stressing and whole process of walking around the problem builds a certain thinking, a way of thinking in your head as a human, and that the pain of going through this process itself is the value, not even the last final architecture, but this ⁓ walk around the problem is the point.
Barry: Yes, exactly. it creates an idea in your head that you're constantly stressing that grows over time and allows you to use your cognitive abilities to actually produce something. We haven't seen that those things exist in LLMs. If they should exist in LLMs, then we can all retire. We can go home. It'll be over. They can use residuality and then we won't have to write software anymore and I can go fishing. And that would be fantastic, but I really don't think that we're there yet. But obviously, I mean, don't try and predict the future. We don't know what the future holds. Something could change, something could happen. Perhaps a little tweak, perhaps the addition of another thing could make these tools much, much more powerful. think that's what people are holding out for. ⁓ So one of the consistent arguments you'll see is this is the worst it will ever be. There's an idea that these things are going to keep getting better and better. And perhaps they will solve these problems. But we're not seeing that right now. But I suspect that if we do get to a point where some kind of AI is doing architecture for us, because that has to be boiled down, it has to be reduced to something, I believe that it will be reduced to stress in the environment. And then that will be further proof that this way of looking at architecture is the right way to do so.
Nune: thanks Barry. I I think we can spend another two hours just talking. ⁓ it's a pleasure. But I I wanna wrap this up. if I am convinced and I'm a listener, I'm convinced I wanna try a residual theory, what are my next steps?
Barry: So the next step, and this is really important, so there's a bunch of YouTube videos where I talk about what the theory is. ⁓ The danger with those videos is that they tell quite a good story and they make it seem easy. It is not easy. So everything that you've ever learned from the engineering paradigm is going to be contradicted by these ideas. You're going to find it. So the basic idea, a random simulation of stress will produce an architecture more likely to survive off spec. sounds reasonable. Everyone thinks they know what that means. But when they come to actually trying to generate random stressors, they're going to find it difficult because these old tools like risk management and scenario analysis will snap them back into ⁓ believing in a world that's predictable and controllable and those impulses are hard to overcome. the next step after watching those videos is to actually read the book. ⁓ and really read the book and then start to try and stress. If you're doing this on your own, it'll take a bit of time. But there are a bunch of blog articles out there from people in Estonia who've used the ideas to actually without talking to me, being able to produce ⁓ results. There's a bunch of case studies. There's a talk given in Antwerp last week, a bunch of case studies done in New Zealand and Australia showing that these ideas actually hold. So we can watch videos like that. I've taught an enormous amount of architects at this stage how to do this. If you find one of those and just follow them while they're doing their work. But what you will find is that the theoretical side of things will not make sense because there's just so much, and the subject is easily bigger than object orientation. And everyone allows two university terms to understand object orientation and then a bit of practice. But the way the modern industry is, everybody wants to explain it like in five, they want to understand what residuality is in five minutes. That's not going to happen. You're just going to get yourself hurt if you do that. So read the book. You won't understand the ideas, but you try to implement them anyway. And as you try to implement them, things will start to make sense. And as the people who did the case studies last week said, then you go back to the books and the books suddenly make a lot more sense because you're doing it in real life.
Nune: Yeah.
Barry: And so when we teach the classes, we teach the theory, then we make them do it, then we make them reflect over what they've done with regards to the theory. And then it starts to make sense. It will never feel completely comfortable because what we're trying to do is pull people away from this old way of looking at software architecture, which doesn't really hold. But it's quite sticky, right? Because we feel comfortable there. We feel comfortable in these old ideas about requirements and risks and process and all of that. ⁓ And so watch the videos, read the book, try and do something with it. Try and do something small to start off with. ⁓ And there will be, there are more books coming that will describe in detail how we think and do stressor analysis. There's a bunch of little tricks we can do to make it easier for us. ⁓ And keep an open mind to these ideas. ⁓ I would say as well. ⁓ And don't expect to be correct all the time. That's one of the things that I programmers struggle with. ⁓ When you go from the engineering paradigm of specifications and code and tests into residuality, you immediately have to leave behind this idea that you're going to be correct all the time. You're going to be wrong all the time, right up until the last minute when it suddenly starts to work. And that's bizarre for some people. Now there people who've made an entire career and sometimes an entire personality out of being correct all the time. those are the people who suffer. Those are the people you'll see squealing on social media saying this doesn't make any sense because they've lost that anchor of being correct all the time and they can't make those small steps forward without logic and it doesn't feel correct to them. It feels wrong in their bones. Those people I find they can't be convinced but it takes about three weeks of debate and discussion and I can't do that 10,000 times. So we'll have to find another way to convince those people or let them continue to practice and be correct all the time somewhere else.
Nune: Yeah. ⁓ besides your two books, ⁓ what are and and all the great books you recommended already? I is there something you would like to recommend? Doesn't have to be technical, can be even non fiction, or ⁓ I I know you're also into philosophy, maybe in that realm.
Barry: Yes. Okay. So, one book that I think that is really absolutely worth reading is a series of books by a guy called Nassim Taleb, Fooled by Randomness, The Black Swan and Anti-Fragile. Those three books, read in that order, will give you a completely different way of looking, not at software, but looking at the world around you. And that's what we need to change more than anything, because we know how to look at software, if we're honest about it. Another book that I would recommend is a little bit heavier is Complexity and Organizational Reality by a British complexity scientist called Ralph Stacey. Another book that will make residuality make a lot more sense is called At Home in the Universe by a complexist and a biologist called Stuart Kaufman that talks about random Boolean networks, which are the sort of root of residuality theory. That can be a great book to read. there is, I could go on all day listing books. That's probably enough to get started with. If you're interested in the philosophy side of things, because I've written a whole book on the philosophy of software architecture, then I would say that an introduction to metaphysics by Omri Bagson. is the best place to get a grip on what are residuality's foundations. What way is this guy looking at the world? Because it really is a different, what happens when you start to work with residuality is that you look at the world through completely different lenses. And Bergson is one of those lenses. And it's a very different way than the traditional way we have of looking at software architecture, which comes from a much more mathematical place, the world of Frege and Russell and Wittgenstein. And so this gives us a counterpoint, a different way of looking at the world. And all you still need to read, know, Gregor Hohpe's work on architecture, enterprise integration patterns, you need to know your distributed systems, ⁓ all of those things before you can even begin to apply these ideas. And that's kind of the cost of entry even to this discussion. You to be good, really good at that stuff. you even get near this. I'll be publishing a new book in the autumn which will talk about those ideas, how to work with distributed systems, how to work with complexity from a software point of view and also a history of software architecture which I'm just finishing writing which is incredibly important because we're very very out of touch with the history of our own industry. ⁓ And to the point where the vast majority of software engineers don't know where the word coupling comes from or why we use it or who said it first or when it became relevant and why it became relevant and things like that. And so those things are incredibly important.
Nune: What about some fiction are you into? Sci fi?
Barry: I was never really a big sci-fi, well, was a big fan of Douglas Adams and Terry Pratchett when I was younger. I'm looking forward to getting back to fiction because I've been doing this PhD and I've read way too much software stuff and way too much philosophy ⁓ in the last couple of years. I've been reading some pretentious fiction, which I won't go into, but ⁓ ⁓ It's been too long for me to recommend anything in terms of I'm really looking forward to handling my thesis in September and getting back to real reading and real fiction. It's been too long.
Nune: Yeah. ⁓ we have this tradition where every guest ⁓ leaves a question for the next one. ⁓ and you get the you get the following. ⁓ what is the most benign thing that you are proud of and you didn't get to talk about?
Barry: Yeah. in technology terms?
Nune: ⁓ l the last the person who asked it said that he had a a wow moment when he perfectly parked a car. So it can be anything. Something small that really makes you proud.
Barry: Yeah, okay. Well, ⁓ would have to say that I spend an awful lot of my time fishing. ⁓ And I tend to, when I decide to do something, I tend to zero in on it and tend to go all in. And I've been doing this with fly fishing. ⁓ I've spent, mainly because here where I live in Sweden, the water freezes in the winter so you can't fish.
Nune: And excited.
Barry: So I tend to spend a lot of time in the football pitch in the snow learning how to cast and learning how to distance cast. And ⁓ I currently throw, I think just over 34 meters of flyline. That won't mean anything to anyone, but the world champion throws, I think, between 37 and 44.
Nune: ⁓ Whoa.
Barry: I've had to visit a physiotherapist because my shoulder is gone. I have terrible tennis elbow, but the fact that I can throw a fly that far and I'm going to go, now I'm going to spend all summer doing that in lakes in Northern Sweden and Norway. And I'm incredibly proud of it. And so whenever you can do that, you tend to collections of old men gather on bridges to watch you and go, ooh.
Nune: Yeah.
Barry: And it makes me proud that I can do that. I offer them that kind of entertainment. Yes. It is very much. Yes. So after a year of talking at conferences and traveling around the world, I get to stand in a river for six weeks and just do that over and over and over again. And it's, it's a fantastic thing.
Nune: It's a nice feeling. Must be meditative work as well. ⁓ so what would you be your question to the next person?
Barry: Who is the next person? I don't know.
Nune: You don't know, I don't know, ⁓ to be honest. It's gonna it's gonna be someone who is ⁓ I don't know, ten plus in IT and maybe an architect, maybe senior S R E, someone in that direction, but you don't know them.
Barry: Okay, okay. ⁓ I'm going to ask a really cruel one, ⁓ so ⁓ I want you to ask them if they were sent back in time to 1822 into a room with Charles Babbage and Ada Lovelace, would they be able to help those people build a computer?
Nune: Good. I ⁓ what do you think? I don't think we we could I don't think we I feel like we don't know more than they did.
Barry: I think you'd be... I think... Yeah, I think that we'd be, I think that we'd have some vague idea that there's a thing called a transistor and that we should maybe get some sand and heat it up. But apart from that, I think it would be quite difficult. And I think we might find ourselves outclassed in that room and despite our modern knowledge of these systems. But it's a terrifying question.
Nune: Exactly.
Barry: ⁓ I don't know what triggered it. I read a tweet by someone who said, man, if I was sent back to the Stone Age, I wouldn't be able to help those people at all. I don't know how any modern stuff works. I'd be like, guys, how do you start a fire? like, it's a, think we're so advanced, but yeah, we, there's so much we don't understand about the things that we work with.
Nune: Yeah. ⁓ there is this book, I forgot the name, but it basically describes every important discovery and how to reconstruct it so that I I think it's called the book or something like that.
Barry: Yeah. Yeah, yes, they had it in The Walking Dead, didn't they? Because they eventually got a copy of this is how you build a windmill, this is how you crush green, this is how you grow green, and this is how you generate electricity. I'm not sure they would have like, this is how you build a prefab for computer chips, but you never know. mean, it should be in a book somewhere, right? Yep. Yep. Thank you. Thanks for having me.
Nune: Exactly. Yeah. Alrighty, thanks a lot, Barry. Thanks for coming. Yeah, that was Barry O'Reilly, twenty-five years in architecture, former chief architect at Microsoft, and the person who decided that magic the rest of us are running on was worth turning into philosophy. His books are Residues and the Architect's Paradox I'll link in the description. If this one made you think, send it to an architect on your team who's been running on instinct that they couldn't quite explain. I'm Nune and let's keep root causing this.