"Residues" & "The Architect’s Paradox"

Genesis of the Residuality Book

Jacqui Read: Hello everybody and welcome to this new episode of the "GOTO Book Club." I'm Jacqui Read and today I've got the pleasure of talking to Barry O'Reilly. You may have heard Gregor Hohpe interview me on the book club about my book "Communication Patterns" a little while ago and now I've got the pleasure of interviewing Barry O'Reilly for his book and he's actually got a couple of books. So there's "Residues: Time, Uncertainty, and Change in Software Architecture" and we're also going to talk a little bit about his brand new book which is called "The Architect's Paradox." So welcome to the Book Club, Barry.

Barry O'Reilly: Thank you, Jacqui.

Jacqui Read: I think we're going to have a very good conversation today because I particularly love all the talks that I've seen you do at various conferences and online and also these books which I have read. So can you tell me a bit about yourself and how your "Residues" book came to actually be?

Barry O'Reilly: I have been in the business for I think 26 years, which is a shock just saying that. I worked as a dev originally, so I'm originally a mathematician. So it's the end of the night, did you come out of university? It's finance or computing. Luckily, I went down the right trouser leg and then I worked as a dev for a few years, did a lot of integration, back end service oriented work, became an architect, worked at Microsoft for many years, was the chief architect for...chief solutions architect for Western Europe there for a while and also globally, responsible for the solutions architecture community at Microsoft where I had to do...I love teaching. The question that we were trying to answer at that time was very much what is...what do we teach architects? How do we create the next generation of architects, especially because we had this massive change going on with the cloud. Everything was changing, everything was being turned upside down. What does architecture mean in this world of cloud? One of the questions, one of the projects I got was what you need to teach the next generation of architects. I said to my bosses, well, what do you want me to teach them? They said, well, just teach them how to do whatever it is that you do. I had to sort of walk away from that and reflect over it and realize that I have no idea how I do what I do. I have no clue. I do my job. I turn up at meetings. Everyone seems happy. I talk. I get paid. I haven't really thought about it at that level of detail. How do I teach this to someone else? I realized after a while that I didn't actually know what I was doing. It's all reflex. It's all gut feeling. It might work, but it's not reproducible easily. The only way for me to really teach someone I was starting to be afraid of was for them to follow me for a few years, which is how I learned to do architecture, just by following someone and asking annoying questions. And eventually, I started to talk to colleagues, I said, how do you do what you do? And sort of woke the same existential crisis in them as well. I don't know how to do what I do. So I started trying to formulate what it is that we do. And I realized that the thing I had in common with other senior architects or people who were finding this easy to do, but not easy to explain, was that we all could cope quite easily with uncertainty. That when things were uncertain, when they weren't defined, when we had stakeholders who didn't know what they wanted, didn't know what they were trying to achieve, didn't really know anything, and instead of bullying them and say, well, then we can't build anything, we would say, well, okay, let's, let's work through this. Let's get to a point from this uncertainty, let's make it work for us. Let's build something even though it's uncertain.

And from there, I started to put together some teaching courses. I came up with some ideas about what made it more concrete, what is it that we actually do. Back in those days, I started to use the word stress. I realized that what I was doing was stressing my own ideas until they fell apart, and then rebuilding them, and doing this consistently until it felt safe. And that was how I originally started to describe it using sort of the parallels with the ideas in Nassim Taleb's work mostly. Then I left Microsoft. But once I left Microsoft, I...because I wanted to travel a little bit less ironically, so I've ended up traveling more. I kept getting calls from people saying, hey, can you come and talk about those ideas that you mentioned? Can you write about this? And then I, eventually, ended up on a big stage, got a little bit of attention for these ideas. And I thought, you know, I don't want to do this typical thought leader thing. I want to do something a bit different. So I decided to make a PhD out of the whole journey, went back to university, started to take the ideas that I'd put together, and started to really put them through the mill and torture the ideas. And that led to a whole bunch of academic articles that I published on the invention of the idea of residuality, which is that an architecture isn't a set of components, but a set of collapsed structures on different timelines that can be modeled in a very, very different way. And then realized pretty quickly that the academic articles weren't anything that developers wanted to read. They were really dense, really heavy. They had the purpose of showing other academics, I was here first, to go away. This is my area. They weren't really written to be read.

Last year, Mathias at Domain-Driven Design Europe said, "Hey, every year we give a little booklet away at our conference. Can you write one?" And I said,", I can do that." That's it. That's exactly it there. What happened then was I went home, I thought, right, I'll start writing this. So we had loads of time. I sent a little message to the team there. I said, right, guys, it's going well. I'm on about 200 pages. And they sent me a sort of panicked email back saying, "No, we don't want 200 pages. We meant like 16 pages, like a booklet." I'm like, oh, oh, it's okay. And I thought, that's going to be...this is going to be tough. I'm not even sure if I can do this. And I did a keynote in Munich. And I woke up the next morning after the keynote. And before I'd gone to bed, I thought, hey, I'll have to send Mathias a message and said, I'm not going to be able to do this. I can't get this down to 16 pages. And so what happened was then I got a text message from Lufthansa who said, hey, we're going to strike today. So good luck getting home more or less. I woke up and I thought, okay, I've got some time to kill. I'm going to spend most of today in airports in various European cities. So I'll just start writing and I started writing on my phone. When I touched down at home in Stockholm, I had just written "The End." And that was...I had a book. It was a little bit more than 16 pages. But there's a little bit back and forth. And eventually, we compromised on 72. That's the book. That's how "Residues" came to be. And it turned out it worked. It's a much more accessible version of the ideas than the academic articles. And hopefully a little bit more fun to read. It's had quite a few years of being...the story being told on stage to refine the ideas. Get them all in the right order because there's quite a lot going on in that book. I usually say it's just as involved, just as big as object orientation. It should take about the same amount of time to be able to grasp all the concepts and have a good handle on them.

Jacqui Read: I was gonna say I think it's more than 16. But yes. I really like kind of one of the things that I think is really good about this book is that it's got a lot in there, but it is quite concise in how you've done it. So it's interesting to hear the story of why you managed to, or you had to get it so concise. 

Recommended talk: Communication Patterns • Jacqui Read & Gregor Hohpe • GOTO 2025

The Role of Uncertainty in Software Architecture: A Defining Challenge

Jacqui Read: You mentioned the word uncertainty a bit. And I noticed that it's actually in the titles of both your books, because the full title of your new one is "The Architect's Paradox: Uncertainty and the Philosophy of Software Architecture." So why is uncertainty so important for software architects?

Barry O'Reilly: I think that for me, when I started to think about what is it that we do, what's the difference between an architect and a programmer, what is it that an architect does, that it came down to uncertainty as the defining feature of our work? That's when...when you need an architect is when the uncertainty gets to be too much for the rest of the team to handle. When the requirements are too vague, when the direction isn't really set, when no one's quite sure what we're trying to achieve, or if we can achieve it, that's when you need someone with a slightly different view on things, a slightly different way of looking at things. That's when everything comes together and you need someone who can cope with that uncertainty. And that is what, as I said, that's what I noticed that the senior architects were...seemed to be fine, their skills were fine-tuned towards handling this constant uncertainty. I usually describe architecture as decision-making in the face of ignorance, we have to make decisions about software structure for a future that we don't have access to, I can't describe it, we can only guess at it and we always guess wrong. Every time we build something, we're building something based on a set of assumptions that we know are going to be proven wrong in the future. There's this deep level of uncertainty in what we do. This is the thing that separates the programmer from the architect, because in programming everything is mathematical, it's about writing code that's correct, proving that it's correct, showing that you've written your code to a certain specification. For the architect, there's no chance that we can ever be correct, because we've got to build structures based on a business context and that business context is moving constantly, it's constantly changing, and it's incredibly difficult. If you don't learn how to, not master because we can't master it, but if you don't learn to be comfortable in that uncertainty, then architecture is going to be something you experience as incredibly difficult. It's central to the problems we have to solve and it's central to our skill set to be able to work with and describe this uncertainty, which by its very nature is difficult to describe and difficult to work with, and not just for us, but for every other role that works in and around our projects. Uncertainty makes everything difficult and it's our job, I believe, to take care of that uncertainty, to turn that into something concrete, to be able to bring that to a code structure that's going to be able to survive in the uncertainty in the business environment. I think if you take away the uncertainty and everyone knows what we want to build and the specification is easy to write and everyone knows what it's going to do and whether it's worked or not, then you don't really need an architect. Programmers will be able to cope with that on their own. That's what they're trained for. And so uncertainty is the thing that I've seen as the defining aspect of our work that makes it our work and the defining skill set of architects who I know who can do the job.

Jacqui Read: I think one of the things that I thought was really interesting in the book is how you said that software engineering has had lots of serious problems due to trying to import ways of thinking from traditional engineering. Do you think that causes some big issues when it comes to this uncertainty?

Barry O'Reilly: I think that it's an instinct and the instinct was to kill the uncertainty and get rid of it. And I think that in 1968, whenever all the big guns from our industry got together in Garmisch in Germany for the NATO conferences, they got together to talk about why do we suck at this? Why does it keep going wrong? Why are we always late? Why does it never work? Why is this so hard? And I think at that time they were looking at other engineering disciplines . If you go back to the '50s and '60s, programmers were very close to the other engineering disciplines because there's a lot of work with screwdrivers and soldering irons and we were actually working on the machines. What happened was that they would look kind of longingly at their industry colleagues, their other engineers, and they would just do some equations and get it right and say, I know that this bridge won't fall down because I've done these equations, I've done all the work up front. We were kind of jealous. When we got together, when they got together in '68 and they said, how do we solve this? They said, well, we have to do engineering, we have to be like engineers, we have to be certain about these things. That brought with it a whole bunch of tools, tool sets and ideas and thinking, where uncertainty was the enemy and it was to be beaten and battered and pushed out of the way until it wasn't there anymore and until we could be certain. This has its roots, as I say, in the second book, it goes back to thinkers at the turn of the century like Gottlob Frege, Ludwig Wittgenstein, people who were looking for certainty and logic as the core of our very reality in our language. A lot of those things all came together. So Von Neumann and Turing, their work rests on these guys. Then what happens in '68 is that the same kind of thinking leads us to adopt this thing I call the engineering paradigm, where we pull all of these ideas from other engineering disciplines. And every time we fail, the assumption is we're just not good enough engineers, we're not good enough at being engineers. The question of uncertainty gets swept under the rug. And it's only now, I think the agile movement was the first big rebellion against these ideas. I think that everyone, many, many really good engineers and architects had their own personal rebellions against this way of thinking. They figured out how to exist, how to build outside of these sort of narrow dogmatic ways of thinking. But the agile movement was the first time a whole lot of us stood up and said, this is not working. The agile movement, their focus was on process, on how we built and delivered and managed software. They were attacking the same things. As I'm talking about the fact that you can't be certain about these things. But what they didn't really attack was our conceptual way of thinking, the way that we conceptualize a business context is also very rigid and imported from engineering. And so that's what I'm now attacking with these books and saying that the way that we think, conceptually, is built upon 2000 years of thought. And it's got some baggage, it's got some problems. And if we take a few steps back and rethink what we do, how we do it, how we think about the business context in relation to software structures, and why we think about certain things in a certain way, then we can solve a whole lot of problems when we do that.

Recommended talk: DDD Today - Modeling Uncertainty • Vaughn Vernon • GOTO 2017

Jacqui Read: I think that's very true. I think a lot of people want to know what we're doing, exactly when it's going to be done, when it's going to be in production. And you can do that if you're creating a car or something. But if you're creating software, you just can't. I would totally agree.

Explaining Residuality

Jacqui Read:So a lot of people are probably thinking, okay, residuality, what is it? Can you give us a sort of overview of what residuality does and why architects really need it?

Barry O'Reilly: Yeah, it's really difficult to do in a short time frame, but I'll try.

Jacqui Read: Just a brief one.

Barry O'Reilly: It all boils down to the statement at the start of the book that says that a random simulation of stress is more effective than gathering requirements. It's more effective than trying to predict risks. It's more effective than reacting to change as change happens. By random simulation, I mean, just randomly making things up that stress your conceptual model of a business context and allowing that business context to collapse. And so what we do is we start off with a naive understanding of the business and we sketch a naive architecture. And then we stress it. We just make something up. We say something's going to happen in the business environment. The competitor is going to drop their price. There's going to be a drop in the dollar against the pound. There's going to be a drop in the price or a rise in the price of a raw material or energy or a change in customer sentiment. Something changes in the environment. When that something changes, what happens to our conceptual model? We look at it, we say it collapses. What happens to our actual architecture? We look at our actual architecture and we say it doesn't work anymore in this new world when this change has happened. It collapses. And we say, well, what's left over of our architecture? We call that the residue. We say, well, this bit's still running, this bit's still working, this server's okay over here, but these components no longer do what we need them to do. This bit's broken. Then we ask, well, what do we need to do to change in our architecture to make sure that when this change happens, that the collapse is more acceptable to us? And then we come up with a little delta. We change our architecture a little bit and we call that a residue. That's the leftovers of the system. What we're doing is we're optimizing the leftovers, not optimizing the actual system. We're optimizing the leftovers and saying, this is what we want to happen when something goes wrong. That residue becomes a unit. That is a building block of our architecture. If you come up with enough of these random stressors, what will happen is that you will have a whole bunch of these residues, which you then combine using some very clever techniques with matrices into a single coherent architecture. Then at the end of that work, you can mathematically prove that this architecture will survive better off spec. It will survive for things that haven't informed its design, that it hasn't been designed for. What we get out of that is a very structured way of working with a mathematical result where we can say at the end of our work that we've actually achieved something here. What it does is it gets rid of a lot of the baggage of traditional architectural work. It makes it really, really fast to investigate and to come up with an architectural sketch with a design. It embraces the uncertainty in our environment. It's just that we don't know what's going to happen. We're not going to spend any energy trying to predict what's going to happen, trying to control what's going to happen. We're going to work in a very many different trouser legs that can happen in the future of this particular system. We're going to ask how we can integrate all of these potential systems together, giving us the result of a system that can survive things that it hasn't been designed for. With that, we're changing the goal of architecture away from the correctness of the programmer to the criticality, which is the ability to survive unknown things off the architecture and separating those two things from each other. And so these ideas pull in a bunch of thinking from different philosophical schools of thought than the traditional ones that inform software and computer science and tools from the complexity sciences, which is an entire discipline dedicated to how we deal with things that we don't understand. And what this gives us is an entirely new way of thinking about architecture that turns out to be quite fun to work with. What it tends to do when architects use these ideas instead of traditional tools is that it mitigates and manages a whole bunch of the risks that you'll see in traditional software architecture. You'll see projects that fail for reasons of performance, for reasons of rapid change that's unexpected, for reasons of security flaws or weaknesses, for reasons of scale. Residuality naturally builds in defences against the traditional kinds of architectural failure that the industry has become so used to.

Fun with Random Stressors

Jacqui Read: I definitely agree with that, with the randomizing sort of approach to finding these different things. You've talked about stress quite a bit. I remember in a talk that I saw by you, you said that there were, I think, electric charging stations for cars. In one instance, somebody actually put, I think, either bacon or ham into one of the charging ports or something like that.

Barry O'Reilly: It was...

Jacqui Read: I can't imagine that ever being on the risk assessment of that project. Have you got any other kind of funny or favourite sort of stressors that you've come up with or other people have come up with?

Barry O'Reilly: I'm not sure if they're funny because they're mostly tragic.

Jacqui Read: Okay, tragic.

Barry O'Reilly: There are patterns that you see. There are things that we miss routinely in our industry. One of my favourite things that's happening right now is these ideas have been spreading rapidly. Last year, I taught 600 people how to use these ideas. I get a lot of emails from them and they'll say, we said that this thing might happen. We created the residue. We integrated it into our architecture. Everyone said we were mad. We were nuts. That's never going to happen. Then it happened and the architecture survived. The gift that I've given many of these people is that they all get to do the I told you so dance. It's fantastic to hear those stories. That particular story is hilarious. The thing is that I've worked with many different companies doing exactly the same thing. As I talk to them, they'll say, that happened to us too. The things with the chargers. So that's quite interesting.

My favourite story with silly stressors is when I was talking to my professor, who's a professor of...his background is mathematics and design. I was talking about random simulation. He said, you know, if it's really random, can I just make up any word and it will be a stressor? And I said, yeah, absolutely. You can do that. He's very sceptical, at this point, because he thinks very mathematically and rigidly. We were talking about building a system for the National Health Service. He said, okay, so if I just choose randomly, the first thing that comes into my head is ice cream. How is ice cream relevant to my system? I said, well, we're building a system for the National Health Service. Let's take ice cream. Let's say that the government in order to try and win some votes takes away VAT from ice cream. There's a massive boom in the ice cream industry. Ice cream is super cheap. Everyone's eating it all the time. It becomes a huge cultural thing and the centre of everyone's culinary experiences, even more so than it is today. And there's a huge explosion in ice cream, which leads to 10, 15 years later, a huge explosion in diabetes, which means that you have an enormous number of people suffering from one disease. What will happen in the system if an enormous number of people are suffering from one disease because you've built a system that assumes all possible diseases, all possible things? What happens if there's a huge tilt towards one particular thing? And he had a look at what he was working with. He said actually COVID was an example of this. This can happen if we suddenly become very focused on one thing and it would change how we architect the system in order to be able to give more resources to one particular thing in the system. So ice cream works. And he said, okay, so he starts to become a little bit less sceptical. And he said, what if I just open up the dictionary, point to a word? Will that work? I think we'll try it.

He opens his dictionary, points to a word, he says “shed”. The word is “shed”. How is shed relevant to this? And he thinks, I've got you now. You won't be able to stress this system with a shed. I said, here's a really simple stressor. Doctors and nurses start to offer services in their garden sheds to patients. Will the system cope? Will the architecture cope with this? And he said, well, the architecture won't cope with that because it's not built to be distributed to that many different places that are small with mobile units. That would be weird for the architecture, but it's never going to happen. And then I went to Google and I said, actually, I read something about this and there was a proposal from the government to start...or from the opposition, I think, to start placing little mini emergency rooms outside of nightclubs so that when people started fighting with each other after the nightclub was closed, in the queue for the kebab shop, that there would be immediate medical attention so that we could stitch people up in place and not fill up the emergency rooms on the weekend. I said, that is a shed and that is going to hit the architecture of the system. At that point, he's like, okay, this actually works.

I think that's one of the things that when we do the workshops that people really enjoy is this freedom. It's so much less stiff. Instead of getting a stakeholder into a room and torturing them and saying, how exactly does this work? What exactly do you mean when you say customer? People don't actually like those conversations, our business stakeholders say. That's why they don't like us so much. And this instead allows us to get to a very coherent, concrete and proven architecture. That's a lot more fun when you think of these kinds of examples. It's quite difficult to get some people to play along with this because it's so far-fetched. I was working on a project many years ago with a mining company and they had a problem with it. So we were building units into the vehicles that they used deep in the mines and we were trying to get telemetry data out of those vehicles. At the time, there was an article in the newspaper about Google putting base stations in little hot air balloons and sending them floating over places so that you would have Wi-Fi reception, maybe at a concert or something. I said, why don't we send...what would happen if we were able to send a balloon down the mine? Everyone said, that's ridiculous. That's never going to happen. So we won't prepare the architecture for that. But these days, it's common to send a little drone with a Wi-Fi unit right down into these kinds of places, hard to reach places and get Wi-Fi signals. Sometimes, just being a bit silly, it's incredibly difficult for some organizations to do, but it allows us to really explore our conceptual models and our architectures and how these kinds of things can break. And breaking them is the whole point.

Recommended talk: How to Deliver Quality Software Against All Odds • Daniel Terhorst-North & Julian Wood • GOTO 2024

Embracing Imagination in Software Architecture: From Playfulness to Robust Design

Jacqui Read: I think I can imagine a lot of people when they start trying to generate these stresses of feeling a bit tense about it and just coming up with all these technological things that could happen. And then once you get into it, I think it's the kind of thing that can be a lot of fun.

Barry O'Reilly: When I run the workshops on this, when I'm teaching people how to do it, we usually divide into groups of three or four. Almost every group will have one person who's very cautious and very technical, and they'll give you sort of the disk fields and network fields, typical kind of technical stressors. There'll be, at least, one person who absolutely loves it and goes completely bananas. This is, I'm finally free. I can finally be open about the imagination that I use in my everyday job. Because people do this, but they tend to keep it a little bit hush hush because they don't want to admit that I'm being a bit silly to get to these points. And it's always a joy to see people say, oh, okay, I've always done it like this, but I've done it quietly because I didn't want everyone to think that I was weird. This is how we arrive at solid system designs.

Jacqui Read: They might come up with something like what you've got on the cover of the book with me here, with the monster.

Barry O'Reilly: One of the original lessons I used to teach people was to show them that here's the stress, a giant fire breathing lizard comes out of the sea, destroys your city. What's your residue? What's left over? And it's like your customers are, you know, busy. There's a lizard on the loose, their houses are on fire, the data centre is gone. How do we counter this? And that's very difficult for people to deal with because very logical people will say, but there are no lizards in the sea near where I live. It's like, how do you know? But that's a reasonable conclusion, I guess. But the thing is that what that asks is if this did happen, where would your architecture crack? Where are the fault lines in your architecture? And then you can work backwards from those fault lines. And you can say that we're vulnerable to all kinds of things that would cause this fault line to break, to be a problem for us. It might not be lizards, it might be flooding, it might be social unrest, it might be a pandemic where people can't actually travel into the city. It might be an invasion. There could be any kind of issue that is similar that will cause your architecture to fail along the same fault lines. And once people realize that connection and there's a mathematical relationship between static systems like software and complex systems like businesses, it makes it possible to manipulate this and to leverage this and to get to a decent system design without actually knowing every single little detail about the particular environment that we're working in.

If you look at the way that senior architects succeed, they deliver architectures that work, that last for a long period of time, that don't fall down easily. Those very same senior architects who succeed with that, they're not able to see the future. They didn't look into the future and say this is going to happen and this is going to happen. They're using the same kind of imagination and intellectual playfulness to get to the design as what we're using here. It just seems strange when we openly talk about it because prior to me saying these daft things, the industry was focused on the engineering paradigm. It was all very serious. It was, you know, we're going to have smart requirements and you're going to write them down and you're going to force people to not be ambiguous. We're going to be rigid and logical about everything. When you try to do that, that will lead you to very crackly, brittle architectures. When you're allowed to use the full resources of your imagination and your experience, then the architectures you build are going to be stronger and better and more related to the context that they actually survive in.

Jacqui Read: I think one of the things I love is that you need to use your imagination, have an imagination for this, but it is maths under the hood, sort of supporting all of it, for anyone who's sceptical.

Barry O'Reilly: Yes, and that's one of the nice things when you're delivering a talk about this. So first of all, you scare everyone by talking about this use of imagination and you've got all these logically trained software engineers in the room thinking, no, this can't possibly work. Then at the end you say, and here's the mathematical proof. Hold on a second. This is real. Tthat's one of the reasons why many years ago I chose to take these ideas into a PhD program to really, you know, force them through that mill to torture the ideas and make sure that this thinking is robust, it's mathematical. There is a scientific explanation as to why this actually works, because it's counterintuitive. It goes against everything that we've been taught, everything that we believed in our industry for decades. It goes against all of those things, which is why it gets attention as well. People are, what is he saying? That's insane. And then it's nice to be able to say, and here's the proof, here's why it actually works in real life.

Recommended talk: Platform Strategy • Gregor Hohpe & James Lewis • GOTO 2024

The Architect's Paradox Explained

Jacqui Read: So your new book is all about the philosophy of software architecture. So a lot of people might be thinking, why do we need philosophy in software? We've kind of, yeah, we can go with this, okay, we need our imagination, but why do we need philosophy when we're creating software?

Barry O'Reilly: One of the things I find when I was trying to convince people that this was a good idea, good way of working, one of the things I find was that many of the ideas in software engineering all share a kind of base philosophy, a default philosophy that you can trace back from Dijkstra to Von Neumann to Turing to Russell and Wittgenstein all the way back to Plato. There is a philosophy that we have in our industry that we inherit, that we're not aware of. And it comes from our computer science departments who get it from all those people I just mentioned. And it's very, very logical, of course, because we're software engineers. And the book is called "The Architect's Paradox." And "The Architect's Paradox" is that the logical thinking that gets us to computing is absolutely hopeless when dealing with business context. But it's the only tool we've got, so we keep on using it. So we're destined to be able to build software, but we're destined to also fail with it very, very often because of the way we think. Once you start to scrape at the surface, you realize that this default philosophy is in all of us in slightly different ways, it's slightly different people, but it's in all of us. Once you realize that, you realize that the things that you believe are not your own beliefs, but you've inherited them from your education, from the wider industry, from the people around you. And as an architect, once you start to really explore why do I believe that everything should have an interface? It's because someone told me once, or I read it in a blog, why should everything have an interface? And once you start digging into the philosophy, which is really, really interesting, you'll realize that it might feel like, hey, we're these cool, hip people on the cutting edge of modern technology having this discussion for the first time. But what you realize is that this exact conversation with slightly different vocabulary was had in a market square in Athens two and a half thousand years ago, then you realize that there might be something that we can learn from philosophy about the way that we approach problems and the way that we think about things. And once you're open to that, once you're open to the fact that I have a default philosophy, it's possible to change how I look at the world, then there are entire seams of thinking and ideas that can lead us to new ways of thinking about philosophy, thinking about what we do through the lens of philosophy, and understanding what is it we do? What is it that we think about? So one of the things that an architect does is creates conceptual models. A lot of those conceptual models never make it onto paper. They're in our heads as we work through a business context and we map it to software. Those conceptual models, where do they come from? How do we create conceptual models? Why do we believe that they even exist? Why do we believe that they're going to have any relevance to real life? And why do we believe that we can map them to software? Those are huge questions in the philosophy of technology, which haven't really been touched. And by asking ourselves these questions, we can start to understand our own biases, where we come from, why we think a certain way and, ultimately, get to the question of why do our architectures fail so often? What that book does is it helps readers understand how I got to residuality through philosophy, and it also helps them investigate their own thinking. Say why do I believe this? Why do I think this? Where does this come from? And many people find that very interesting. And, ultimately, it helps them to change their minds. Why do I think like this? Why do I believe that these things are the right way to do things? And it's also then as a side effect, it's an introduction to philosophy too, because I go all the way from the pre-Socratics to modern day philosophers, with all the computer scientists mixed in. And it gives people an introduction to philosophy, which we don't get to do because we're too busy studying maths and algorithms and data structures and all that easy stuff. And this is a much more, this is a kind of fun introduction to philosophy for software engineers as well. But at the end of the day, residuality wouldn't have been possible without a philosophical understanding of where we've come from, why we think the way we think, and sort of challenging the way that we think as software engineers.

Jacqui Read: That's really interesting because I think one of the things I really like about your work is the fact that you are going into these sorts of different areas. And it's something that I did when I was writing my book as well. I think it's important that we learn from all these different areas. Now we are starting to run out of time. So I want to ask you, where is the best place for people to find you and your books?

Barry O'Reilly: I'm most active right now, I think on LinkedIn, which you've probably seen. I think that's the most stable social network at the minute, especially for working with any of these kinds of ideas. So you'll find me there. I work out loud, which I think is scary, but also beneficial both for my own work and for the wider community. As you said, I'm on stage at lots of conferences all over the place. So you'll probably find me on a stage somewhere yapping about these things. And I'm also on BlueSky as well. The books are on Leanpub. You'll find the links to the books and all of the academic articles that I talked about as well. If you want to dig into those, those are free on my LinkedIn profile as well. So that's mostly where you'll find me.

Jacqui Read: Brilliant. Thank you so much, Barry. Thank you for talking to us today. And I'm looking forward to finishing your second book. I have started it. I haven't finished it yet. I can highly recommend Barry's books for everyone to have a look at. And I want to say thank you to all the viewers for tuning in today. And I hope to see you at another Book Club again soon.

Barry O'Reilly: Thank you, Jacqui.