Expert Talk: Scaling Down Complexity in Software

Software shares multiple similarities with living creatures. Embark on a journey with Kevlin Henney, an independent consultant & speaker, and James Lewis, consultant at Thoughtworks, to uncover some of the aspects that make producing software so complex from trending frameworks, that help you understand the human component, to its disposable aspect and the way it influences companies and solves real-world problems.

---

Intro

Kevlin Henney: Good day and good night to you, wherever you are and whenever you are watching this. This is another GOTO Unscripted interview with me, Kevlin. We are recording this at GOTO Amsterdam 2022, or 2020 as it would've been, and today I am joined by James Lewis Lewis. James Lewis.

James Lewis: Hello, Kevlin. How are you doing?

Kevlin Henney : I'm all right. So James is...let's see, let's get this right, technical director at Thoughtworks, involved in the technical radar and Tech Advisory Board. There's a lot of word tech in there, isn't there?

James Lewis: Yes.

Kevlin Henney: Yes. Three Ts.

James Lewis: Tech at the core, we say.

Kevlin Henney : Tech at core. There we go. Now, very much at that core, you are going to be giving a talk here, in fact, more Ts, on Team Topologies, there we go, Ts, software architecture, and complexity. What's it all about?

James Lewis: What isn't it about I think is probably the real question. I've been fascinated over probably the last 10 years or so by the ideas coming out from complexity science, right? Complex and active systems thinking. And particularly, a lot of the work that was coming out of the Santa Fe Institute had to do with something called generative science which is the third type of science.

And after doing, a bunch of research and reading a lot of papers from them, I started to see a lot of similarities with the previous work I was involved with around microservices and software architecture, and distributed systems, in terms of the way complexity rises from simplicity.

One of the things I think when you look at microservices and the original sort of ideas behind microservices was this idea of taking big things. Sam Newman's got the line about, what do you do if you've got a big problem, right? Well, you turn it into lots of small problems and solve them independently.

Recommended talk: Monolith Decomposition Patterns • Sam Newman • GOTO 2019

That was one of the founding ideas of taking big things and making them a lot smaller and having them, isolated from one another, so that, multiple teams could work on them independently. So you could scale, development effort, and so on and push governance and things down to those teams.

But then, there's been, as I said, a lot of research from Santa Fe that talks to some sort of underlying, almost, physical properties of...It appears everything is more or less like reality in some ways around how different types of systems scale. They seem to have similarities with some of those ideas around decentralization, around, as I say, pushing information down to the point toward the people who know the most, as opposed to them knowing the least.

So, that's the complexity bit. The software architecture bit is the link with microservices and my journey over the last sort of 10 years understanding what I think is maybe some of the underlying principles on how that relates to complexity sites.

Team Topologies

James Lewis: Then the Team Topologies bit I think is fascinating. There are very few books or pieces of research, that you find I think in our industry, which almost immediately become canon, becomes a sort of immediate reference work. And I think Team Topologies are one of those pieces of work.

The reason I love it, and I'll talk about this tomorrow is it provides us with domain-driven design terms, a ubiquitous language to talk about structure, to talk about...and, via Conway's law, therefore, the structure of software as well, right?

I also relate quite strongly to the Team Topologies folks because I think a lot of the work it's almost a metastudy. It's almost a big literature survey in the same way that microservices was a big literature survey in a sense. It was taking a bunch of stuff that we know works and doing them all at once and turning up to 11.

Kevlin Henney: No. He only set it up to 10. I don't think he'd watch the...

James Lewis: He watched it.

Kevlin Henney:  You see, because when I looked at that, it's just like, oh, now you turn the dial up to 11.

James Lewis: That shows how much younger I am, getting secondhand.

Kevlin Henney: There are a lot of interesting things in there. First of all, one of the things you're kind of pushing towards is that a lot of the complexity...there's the technical complexity, but there's the sociotechnical aspect.

In other words, software architecture is a sociotechnical construct. It's not just a purely... And I think a lot of people approach it as if it is just a technical thing. You can see this in the diagrams that people draw often. It's kind of my standard lines. It's like, "Okay, where are the people?" It's like, "You've shown me all the boxes and you've shown me data flows and databases and all this kind of stuff." But where are the developers?

The only people are normally the customers. It's like, that's fine. But who lives in the architecture like a building? Who lives in it? It's gonna be people, and those people, in this case, aren't developers.

That shaping factor, and particularly that idea of Conway's it phases in and out of fashion, and it seems to...it kind of picks up a little more empiricism each time round, and that it kind of is properly being acknowledged. I found one of the interesting things, and certainly looking at the Team Topologies stuff that I found interesting because I normally do...the dichotomy that people normally had is this, "Oh, feature teams versus component teams."

And whenever I've talked about it, I've said this is too simple. I want you to understand that there's a whole spectrum here and that when one person is advocating one over the other, it's much richer and more complex. Team Topologies seems to speak exactly to that by offering a richer vocabulary for the structures.

And actually, this is the nature of this problem, therefore follow through to this kind of team structure and so on. It's much richer than I guess the kind of binary view.

Recommended talk: Platform Engineering as a (Community) Service • Nicki Watt • GOTO 2021

James Lewis: Very much so. I think that one of its strengths is acknowledging that not all things are the same. As you say, sometimes we can be very binary. We can say, "Well, either you do this thing." And it's a product team, or you're going across in horizontal layers or, as you say, a feature team, which I guess, you can have feature teams that just pick up the next feature on the queue, right?

What I like about it is it says, "No, actually there are some problems that are fundamentally really hard and you probably need some specialists." Well, I'll give you a couple of examples. There were probably a bunch of mainframes that are sitting in the UK government at the moment with...I wouldn't say three people who know how to run them, because that would not be the case, but not huge amounts of people who know how to run these things, right? These are big, complicated, older systems with real deep specialism needed to operate these things now.

I spent quite a lot of time in front office investment banking and you don't just dump any developer and ask them to do a quant's job, right? I mean, there's a real specialist set of skills that you need to solve certain problems.

I think that's one of the things that team typologies are great at acknowledging, is actually, sometimes you need a...they call it complicated subsystem team. Sometimes you need that. But also you need those product teams.

You also need teams that are solving the problem of scarce resources. We know we need more InfoSec people, deep, good, pull-it-left InfoSec people, but there aren't that many of them. So how do we solve that problem? Get them to act as consultants?

So, I like the richness, as you say, of the model, and also the vocabulary.

Breaking the silos

Kevlin Henney: I think that's interesting because sometimes it's very easy, particularly given the kind of the rich nature, diverse nature of software development is, you can be one part of software development and think that that's the whole universe, and then you go and talk to somebody else and discover that you have no shared experience.

James Lewis: Yes. And even that mode isn't that fast. 

Kevlin Henney: Or they just come out with the alphabet soup that you've never heard. And I think that, in one sense, that's always been the case, but it's more obvious now because we are probably more connected.

I certainly know that that was a... It was a conversation my wife and I had with our neighbor nearly 30 years ago, and it was this kind of lovely bloke.

It was a case of I bumped into her in the pub. And my wife said, you know, "Oh, isn't that our neighbor?" I had chat with them, "What do you do?" Because, as neighbors, you don't talk. And I said, "Oh, yeah. I work in kind of real-time systems," you know. It's all this curly-bracket stuff and everything.

And he works in real estate. And my wife, who was observing the conversation said, "And at that point, you both took a completely different path of the conversation because you have absolutely nothing in common." But these days we are probably more aware of it because these days we are genuinely aware that there is so much going on that no two developers are gonna necessarily be able to speak to each other, and that is exacerbated by the variety of architectures.

James Lewis: No. I agree. I think when we first met, we talked about this earlier, back in the sort of 2006, 2007. Still very much the pattern language, the pattern community was super strong, right?

And I'm not sure if we've lost some of that over the years or where some of that has gone, but I still think we need to be developing these languages by which we can communicate across these divides.

You talk about the pace of change. I'm involved as you sort of said in the Thoughtworks tech radar. So, every six months we get together, and we all bring a bunch of new ideas or new things that have been recommended for us to include, and there are 300 new things every six months to talk about. Three hundred. And not all of them are JavaScript libraries either, right? Not of them are.

Kevlin Henney: 250 of them.

James Lewis: We've got half of it, obviously, estate management and react, but, you know. And then all of it is JavaScript. It is astonishing. I mean, it sort of reminds me a little bit of the fragmentation in the scientific community, right, where it's impossible now to know everything. And now, we're starting to see the advent of machine learning models being used to try and solve the problem of not being able to know everything anymore.

Kevlin Henney: I think that that becomes interesting because it's very easy to be in one corner. So, let's take the kind of full-stack developer notion. Some people are just full stack. And their stack is quite small, but it means that they are typically a cross-functional developer and they're capable of working at the front and back end, but it immediately tells us we have an architecture with the front end and the back end.

That's a huge narrowing at that point. And they're potentially a generalist at that point, but then that also leads to people wandering out to the industry saying, "Oh, everybody needs to be a cross-function developer."

It turns out that there are certain specializations. In the past, I've dealt with game companies and console games companies. It's really interesting the specializations that they have. It's not all just talking to the metal. It's that you have people who are specialized in music. You can't just drop somebody who is non-musical into that role, or somebody, "Right, I'm responsible for the physics of this." Again, that's not just learning a new framework. That's a genuinely different thing.

James Lewis: During the first lockdown, I ended up exploring a product idea that I've had in my mind for quite a while related to some of the things I'll be talking about tomorrow. But one of the things, one of the aspects of it, was a game-like, right? It's a simulation kind of engine kind of game-like. And of course, being a fool, being an idiot, I thought, "Well, you know, what do these game folk know about software development, right?"

So, I'll just write a bit of C#, and suddenly I had that, you know...is it on the 10th floor, you know, any sufficiently complicated oriented system has got a half-ass bug written implementation.

Kevlin Henney: That's right. 

James Lewis: Or I ended up with the same thing, but for a game engine, right? In my code, I've had a game loop and I had rendering loops, and I had all the things that you go to Godot, which is a great open-source game engine. Look, "Oh, it's all there for you, right?"

But also, I think the interesting thing with gaming, with game studios, in particular, is the separation that they have between...and I think this is something we need to learn in the rest of the industry.

We're starting to go on the path with things like the platform product teams, actually, again, Team Topologies, right? Teams that are building tools for other teams. And that's what they're good at. Most people in the game studio aren't. There is a lot of people building tooling to support the others who are using the tooling, aren't they?

Kevlin Henney: I think my first interaction with the games industry is about 2000, 2001. And I'm not going to claim to have any expertise in this, but it's kind like I visit the games industry like kind of every couple of years, you know? And then it's just, like, oh, it's changed and there's this clearer modifications platform separation.

There's a lot more that gets outsourced these days, but there's also a lot more that moves what they're doing with the shape of teams and how the responsibilities distribute and what gets commodified, and that whole idea of the platform.

Again, in Team Topologies, you see that kind of... there are platforms, then there's the recognition of complicated subsystems. Then you have the stream aligned, which gets closest to feature teams. Then, you've got kind of enabling, which is just now, and then you just need a little bit of a push somewhere to make something happen and bring in some expertise.

That's a much more dynamic and to pick up on what we said before, a much richer way of viewing it. And that idea that we have these different degrees. There are cross-functional developers, there are cross-functional teams where we may have everything there, and then you may have, across the teams cross-functionality exists, but the whole brings it together.

It's a more nuanced way of looking at it. I mean, I think everybody would like a simple answer, and I think sometimes it's very easy to fall into that trap. But now and then, you stumble across a domain, and it's just, like, actually I can't casually be a tourist in this.

I've got a couple of clients who do medical imaging. It's just like you can get a whole master's degree in medical imaging and only feel that you're at the beginning of that discipline." That's not one that I can just be a cross-functional developer in.

James Lewis: This is an interesting example from that actually, and it's something that I've never thought would be an interesting example. I've never thought it would be that interesting actually because you've got...these are really deep technical algorithmic problems here, but there's also these complicated domain problems or complex domain problems. Trains.

Have you ever worked with the trains domain? Unbelievably complicated domain. Things turn into other things halfway through, like, halfway through.

You have a train and are fine. It's a train. It's got an ID. In the end, it's a different train. Well, how could it be the same physical... No, no, no, a different train. I say, "No, it's the same train." It's just really complicated and really fun to be in. So some of those problems are super, super fun.

Kevlin Henney: That's a really interesting one because there's a discipline that has grown up and it's massively effective, given the train infrastructure in every single country. But there is a rich domain that's already got of a vocabulary, that's already got a way of working, and it also challenges our ideas of this train. As you said, this train is this train. It's like, "Oh, the content of identity is..." You know, we wander into philosophy here.

The concept of identity is a lot harder than you thought.

James Lewis: It's quite fluid.

Software problems in the real-world

Kevlin Henney: And where trains split or a single physical unit can change its identity on the route, but what if one train becomes two trains and one part takes the original identity? And there are all of these questions that have traditional database people screaming. It's just like, "No, no, no, can you simplify the domain?" No, you don't get to simplify the domain. The domain is a given. You get to simplify how you implement it, but that's a given, and that does challenge people.

But then also it's another case which I think is interesting, and it's perhaps a little different to some of the disciplines that we normally end up with, is that it directly talks about something in the physical world that you can't redesign.

I can redesign a shopping basket. If I'm doing an online shopping thing, then actually I get to shape my world. I can change it as much as I want. There might be common business practices, but I don't have to respect the rules of accounting. We don't get an option on that one. You could try being creative, but somebody will find you.

But when you're starting to deal with rolling stock that is moving things across physical structures and it's just like, "Yeah, my software touches the world and the world touches the software." This is a bigger problem.

James Lewis: I had another, but one of the great things about being a consultant is you get to see a lot of different stuff, right? And this wasn't something I worked on directly, but it's always known internally as the cow project. Talk about the physical world, and it was an IoT project and machine learning project to understand how to optimize milk production for farmers on farms. Again, you can't get much more physical than that.

The brilliant thing about that project is we had BAs, we had some of our analysts in wellies on farms actually with the farmers, because it turns out they wear big gloves. There's another example from some friends of ours, probably joint friends at Equinor, the Norwegian state oil company, and they've got this brilliant case study where they talk about building digital twins, essentially, so AR apps for iPads, I think it's for iPad, or maybe it's a tablet of some sort, to diagnose problems on rigs. So, when they've got a problem, they can point to this thing and it tells you flow rate and all this kind of stuff because they know what the asset is and things.

But, of course, when the developers are sitting in their nice, warm office in Tromsø or wherever they were when developing this, they came up with a thing that when the people who were working on the rigs will have to go in and use it, they're like, "Well, look, you know, there's a force going on." Or, "I'm flying around at this. I've got these thick gloves. How am I supposed to be...?"

I brilliantly put the developers through offshore training, and sent them and gave them their first version of the app and said, "Right, you make it work." And of course, they couldn't. I think that's, again, an intersection with the real-world, software real-world problem.

Kevlin Henney: I think that it's very easy sometimes in the software space to reduce everything to a software problem, and then, I'll reckon...because it goes back to what you're talking about in terms of complexity.

A lot of complexity arises, not just from within a domain, but how one domain of description interacts in a very weird way with another. I'm going to borrow from Michael Jackson. No, not that one, the other one. Michael Jackson the requirements guy, and his stuff on problem frames and requirements. He talks about these domains of description. It's like the way we describe an information system is fundamentally different from the kind of things about a physical system. How do they interact? There's a different story there.

That becomes part of what becomes our software architecture, part of where the complexity arises. Each domain on its own might be simple to describe, but bring the two together, and suddenly, there are all these possibilities.

Recommended talk: Expert Talk: DevOps & Software Architecture • Simon Brown, Dave Farley & Hannes Lowette • GOTO 2021

This is quite literally out in the fields, for the cow example. Quite out in the field trying to discover this stuff.  I have a friend who similarly software, yes, oil platforms. It was just like...that was one of the things he had to have was offshore training.

It takes it, as you say, away from that kind of keyboard view of the world. There's a tendency of many mobile developers not to worry about...not to concern themselves with offline development. It's just like you're assuming you have good bandwidth everywhere. How does this behave when you take that away?

James Lewis: That's another great example from that, which was it was. There was an aid agency actually, and they came and asked for some advice around rebuilding one of their apps. It was some pretty simple app. It was to do with the registration of people's details. Essentially, they were operating in Africa with rescued child soldiers. That was their kind of domain.

One of the sets of requirements was how do we burn this? Because if the camp gets overrun that they're sitting in what are the options that we have? Do I just carry a hammer with me so I could smash the hard drive? Because, of course, if the encryption is a thing, you know. But then the offline thing, there's not much internet coverage if you're sitting in a refugee camp in Africa, in lots of Africa.

And also syncing. It was a distributed system problem because they had one...they had a copy of a database in sort of head office somewhere, and they had to sync the local copy with it with no access... So, they'd put a USB key on a guy with a donkey over a mountain to go. It's like very, very, very, very, very high latency but quite large bandwidth.

Kevlin Henney: The bandwidth, yes. But exactly that becomes part of your problem domain. In other words, sometimes I think it's easy in development to just sort of say, "Well, that's an implementation detail," or, "That's a..." There's a mental boundary that we draw around something to simplify it. So, back to the kind of...

James Lewis: Just on that point, and it comes back to the thinking about the domain design, ubiquitous language, and diagrams and the type of things people draw. I think the big shift we've seen, but it's not...I think it's not quite there yet, is to switch from drawing the diagrams of the technology to drawing diagrams that represent the actual... domain you're working in. So, the business capabilities that you are trying to implement.

I think that's been probably in the last 10 years, 12 years, the biggest switch I've seen. I think that's a super, super important thing because it's the focus on the technology I think that gets us into too many rabbit holes. Technology is a means to an end, unless you are an Intel, right, chip designer, in which case the domain is the technology, but it's the means to an end.

Diagrams in software

Kevlin Henney: We have a strong solution-centrism in software, and people are drawn to the technology, but it's that idea. And it's interesting because when we start looking, you mentioned, diagramming, I think that's interesting because I've had this kind of relationship with diagramming that goes back,  many decades and it's been interesting to see how it's evolved, how it's been taken up or pushed down in various times.

We have something like historically UML was very much anchored in the idea of I'm trying to describe the technology. And, much as people would say, "Oh yeah, you can also describe the domain," that was an also-ran. It was very much... A colleague several years ago kind of betrayed the reality of it when he described everything. It's like, "Oh, he's talking from a C++ perspective. Oh, it's like visual header files. And it's just like, yeah. So, all of that chat about, "I'm trying to do the domain model here," is completely lost on most people. And because it does come from that, and certainly my work with some BAs years ago on a kind of more agile adoption, I focused initially on the developers and then I focused on the BAs, and I got much more traction with them.

Recommended talk: Continuous Architecture in Practice Part 2/2 • Eoin Woods & Simon Brown • GOTO 2021

But what I discovered is that that's not how they're thinking about the problem, not even close. I mean, not even like translatable close. It was just like, okay.

Interestingly enough, we did end up doing a lot of diagramming. But the diagrams that developers would by default try and offer as a common language didn't have anywhere to land. That's not how they... So we chose a different shape, and we chose some standard notation, we chose some nonstandard stuff, but it was a case of like, "Oh, that's not how the BAs are thinking about it." We are developers imposing a solution on a space. UML is another one of those, and people have loosened up a bit in the notation department.

James Lewis: I think a good example of something that works is the visual language in Greg and Bobby's enterprise integration panels. I mean, I think that is a fantastic example of a visual language that exactly suits the domain that they were trying to represent.

You'd be happy to have an OmniGraffle template, with your diagrams, wouldn't you? That'd be pretty cool. My favorite thing I worked on. I'm sorry, I'm full of old stories, so I apologize.

Kevlin Henney: No. No, that's exactly what we want.

James Lewis: My favorite class diagram story, or ULM story, was from a client, a former client many, many years ago now probably back in 2007 or so. They had a classic Ivory tower architect who insisted on class diagrams, "Where are class diagrams?" But we had, like, 40 people writing codes. It was continuous integration before continuous delivery was named, but doing continuous delivery. I think Dave was actually on that. Dave was on that project, I think.

We had a lot of people writing code, committing, multiple times a day, you know, write a test, made the test pass, refactored, commit. That's on the main line.

But where's the class diagram? We're trying to explain: it's like, "Look, the code is from...the class diagram is the code. You can't tease these things apart. The running software is the..."

So, to satisfy this architect, one of our devs every commit would dump out a representation of the entire code base in dot format and then would send a class diagram by graphics to the nearest printer and would print out sort of the class.

Kevlin Henney: That's continuous delivery.

James Lewis: Fifty pages of class. It's the current class diagram, the current class. And you've got 40 people committing once every what, you know, 20 minutes or something.

Kevlin Henney: You see, that's the thing is that it...

James Lewis: It stopped very quickly.

Kevlin Henney: There is this fascinating thing about I think...and this true of all tools, all decisions that were there is this idea that it's just like, "Here is a good idea." But often the bit that's missing is why something is a good idea.

So, then what you end up with is people start advocating diagrams but not understanding what problem they're solving. And that leads to some very interesting and bizarre adoptions. And I have one company where somebody is"Oh, here's the domain model." And I'm looking at it. It's got 10 glasses on it, which is not a whole load.

Then I'm looking at it going like most of these are infrastructural, you know. They're controller-type things. I kind of look a bit closer and it's just like, you do know there are only two actual domain classes on this.

And the developer looked at me and said, "Oh, I wondered if you'd notice." He said because I initially drew the class diagram and there were only two classes on it and it's just like, "Oh, it looked a bit empty, so I added others."

And I said, "Well, there's a really simple reason because your domain is actually from a data point of view, is not very interesting." It doesn't have a rich data model, especially data. Oh, my goodness. There's loads of data, but the relationships between the data are not very exciting, but the workflow, that's where your domain is.

In other words, it's kind of like your projection is wrong because you're a developer. You're thinking, oh, classes, visual header files. You know, that's the thing as opposed to what's the shape of the problem here? Why am I doing this?

Are you drawing a diagram to keep another person happy, because they said the diagram, or are you drawing a diagram to show something that is otherwise not easy to show? And the workflow, that was the invisible thing. It's just like, oh, the workflow is...you can't point to it and yet it's everything this organization runs around. If you draw the workflow, that's where your domain is.

Your data thing's not very interesting, sure, put in the database. But actually, you end up with that.

The disposable aspect of software

James Lewis: And I think that's event storming. I don't know if you've done much event storming recently, but, I mean, I think we've entirely wholesaled off to that in Thoughtworks, because, you know it's been a bit of a revelation actually to be able to have it all. Okay. It's a one-size fit, in some ways kind of a bit of a hammer to solve most problems. But it does surface a variety of interesting things about domains, not just the static, not just the data perspective, the infrastructure perspective, but the workflow.

It reminds me a bit of... Martin Fowler's talks about semantic diffusion. The why gets lost, or the meaning of the why changes in some sense. You see that he talks about that with agile over the years and how, you know, you end up with the cargo cult and you end up with the processes, the means to the end, rather than, you know, an approach that helps you get to the end. And I think microservices are the same. That's also gone through this period of... Why would you break up something into smaller bits? What are the reasons you would do that? And that's, I think, has been lost as well. I'm not sure what Fred's thoughts are on this these days, Fred George. I haven't spoken to him in a while, but  there's still all the questions around, you know, "Oh, with microservices first." And still, most of the time, you end up with a distributed model if built around nouns, you know, and it's...yeah, people don't stop to ask for.

Recommended talk: Sabotaging an Agile Transformation • Fred George • GOTO 2022

Kevlin Henney: But by coincidence, I was talking to Fred George yesterday and this question came up actually. He says the term, and exactly it's this semantic diffusion is otherwise, a term arrives. It has a precise meaning.

I was talking to Fred about this outside of our unscripted discussion, because I said, well, you were the first person I heard talking about this stuff, and you had a concept about microservices that was very much bound to the word micro.

In other words, there was a notion of scale that distinguished it, and that sizing aspect was a fundamental import. It's the idea that you have only a couple of people on it. It is a scale-related thing. It's independence, but it's also a quality that I refer to as high discardability. You know, you could throw the code away. The discardability of code. What happens when I throw this away?

Now, clearly, for a monolith, that's a question that would...you know, if you were to say that at a table you know, a meeting and it's just like...people go like, "No, no, that's not the thing we're gonna do."

No, it's a thought experiment. I want you to engage in this. It's like, "No, no, we can't even think about it." Versus, "Oh, this is so small. Of course, yes. We can easily...we could see the shape. We see the shape of a toll, and yes, I could reimplement that using different technology and just pop that right in there." Another developer could come.

And that was the microelement. In other words, he had a very strong size idea, but he also said... said most of what people are doing is just service-based architecture, but the term itself has generalized to include everything that was not micro. It is services. And there are only out there a few micro things.

Recommended talk: When To Use Microservices (And When Not To!) • Sam Newman & Martin Fowler • GOTO 2020

James Lewis: And you could argue that we've reclaimed service-oriented architecture away from the big vendors, right, in some ways, although they're doing the best and have been doing the best to take it back. But I think the discardability, the disposable aspect of these things, I think that's super interesting.

I think some tropes pop up, almost like they're memes in some sense, right? In the kind of virus kind of sense of the word.

So I did a talk years ago now called "Building Software That's Never Done," right? And it was about what changes in the world if you are building disposable software. What are the practices that are still relevant? What are the tools that we can still bring, you know, from our toolbox to use when we're in this world? Because, you know, talk about the monolith [inaudible 00:31:59] throw that way. You know, but still, for most product managers, most folks who have the money, you know, saying, "Oh, we're just gonna have a team that's gonna build this forever," right? "And when we learn more, we're gonna throw away and start again and we'll build another thing."

It's not even just how people's minds work often. It's, like, the financial structures of organizations aren't set up to support that way of working, right, because you're building a thing which then goes on your books for 10 years, and then it comes off your books, right? That's you build a thing. It goes on your books for 10 years. That's how you finance most of this stuff in most organizations.

This idea that you would have these, and we talked about...in the thing, the paper that Martin Fowler and I wrote, we talked about long-lived product teams. This idea that you're never done, that you're maybe the platform API team and Netflix who rebuild in three different languages over how many years.

I think similarly with things like team structures, right? Again, I've been enjoying reading the work on swarming that's been written about quite a lot. You know, things aren't fixed. We should recognize....we need to recognize that things aren't fixed. Even if we think they are fixed... And again, this is back to complexity science. Even if we think they're fixed, they're not. People go on holiday, you know.

And if I go on holiday for a month and come back, the software will be different than if I'd been there for the month, right? I mean that's an unavoidable outcome of me not being there.

This idea that things are fixed and should be fixed I think is one of these things that has just become an accepted part of our reality when we're writing software. I think that one of the things we are learning I hope is the impermanence of all these structures and the fact that we need to optimize for change and not for permanence if you like.

Kevlin Henney: I think that change is a scary thing, and I think that's actually...I think it is our sort of inability to visualize and conceptualize that change that... It's as developers we often approach things, we want to simplify things. But actually, I'm not even gonna just attribute this to developers. I think as humans. You know, the world is a complex place, so, therefore, we look for simplifications. We look for, "Well, let's assume that that doesn't change."

In other words, we go around, what if I have a set of development principles that everyone follows, and that just simplifies that? In other, we are kind of pushing things into the kind of like the wrong debate. We're oversimplifying. It's just like, "I would like this to be simple." The fact that it isn't doesn't change me...

James Lewis: La, la, la, la, la, la.

Kevlin Henney: And it turns out you can't hear my preference. So, what we end up with is that it bites back. It's just like, "Oh, I have this simple view. I'm going to make a development. It's going to be these principles, and we're gonna follow these rules, and here's this, and I'm gonna push this into this box."

It turns out that it kind of springs out because it's just like, "No, no, no. That's not the nature of this thing." And that impermanence, I think, exactly as you say, even down at the level of an individual going on holiday, that idea is that sometimes people like this fixed idea of teams.

Well, if we could keep that fixed, then that allows us to think... but it's dynamic. And again, Team Topologies expressly sort of say, "You know, this is changeable through the life cycle of a product."

These will align and realign. You may discover new problems that may move you into a different space. You suddenly realize, you know, the way we've made up the teams at the moment is not meeting the class of changes that we are now experiencing. We're set up for a different era. We are quite literally programming in the past.

We are programming according to a model we've built and we've organized our teams according to yesterday's model, not today's.

The half-life of companies, code & devs

James Lewis: But as you say, I think it's human nature, right? And I think a lot of it is people don't know what they don't know, to coin the old phrase. But, again, I think that's why I've been very lucky as a consultant I've seen lots of different stuff.

Most people don't get to see lots of different stuff. Most people get to see... it's the old thing about do you have 10 years of experience or do you have 10 lots of one year repeated over and over again, right? That's the thing.

And often when I work with an organization, half the time my job is to talk about elephant spotting. I can walk in and see the footprints, right, in the butter or whatever in the fridge, right? But then, you know, if you've been working there for a while, you don't get this...you don't question, you don't start to question why do we do things like this? Why are these rules that we've got in place for teams, for how we build software, for the principles that we use? Why? Where do they come from?

This is another thing about exploring the talk tomorrow what happens as companies get older? And there's some really interesting research around... spoiler alerts, but there's some interesting research that seems to point to the fact that, as companies age, those similar things start to happen that happen to mammals when they age, right?

So, they exhibit signs of aging, and they do that by getting slower and by getting kind of increasing depth of hierarchies. And these sorts of things tend to happen over time. And they start to switch in particular from a focus on the thing that made them successful, which is product development of whatever type that they were involved in, to almost keeping the organization running.

And so, rather than invest in growth or new product development or research and development, maybe to overuse the metaphor, they have to spend so much of their budget, of their energy, on keeping themselves alive on repairing damage, if you like, to the organizational structure that inevitably they slow down, they age and often die.

I mean, if you know some amazing facts which are from the book "Scale" by Geoffrey West, which is there's...the half-life of a company on the exchanges is about 10 years. There's 50% churn every 10 years.

Recommended talk: Expert Talk: Managing Complexity in Software • Hadi Hariri & Kevlin Henney • GOTO 2022

Kevlin Henney: And it's dropped. As I quoted a figure in a talk last year and the year before on how much this, this cycle is now moving faster. And what is interesting is that when you look at that, and there's particularly there's a nice piece on kind of the longevity, or a time-sensitive version of Conway's Law, where he looks at ….the idea is that it's not just the forces of the people in the organization as it currently exists, but as they were in the past, because they live on through their code, so to speak, and that exerts a force on the day to day.

Rob explores this, but he also uses a half-life model where he talks about the half-life of various things. And it's just like the half-life of developers is a couple of years. And then we end up with the half-life of actual bits of code being long, and the code is now outliving the companies.

And that's the thing. We're finding there's this interesting kind of shift in the rates, and it goes against our mental assumptions. There is this idea if we were to... You know, we like things to be nested. You know, it's an instinct that is a massively simplifying instant. We see it in our code, you know, blocks, nested inside other blocks, you know, people draw it up in nice container diagrams. This is inside, this is inside this.

It's great and we like the idea that here we have a product and it contains code, and this product is in this company. And it's just like...that's not how it works. When you look at the lifetimes of these things and their influences, it escapes the box, quite literally escapes those boxes. And it's a radical oversimplification. It's far more complex.

James Lewis: I mean, I am quite interested in the idea of self-similarity, as in the different levels of abstraction, because it was one of the things I always talk about in microservices is this self-similarity to a certain extent, especially around things like the single responsibility principles. So, a single reason to change.

I think that there is an interesting argument to be made there that that is a unifying principle up and down think in terms of software architecture, in terms of writing code. You know, I always talk about this idea of chunking up. Dan... I wholeheartedly...wholeheartedly is the wrong word. I just stole it from Dan North, Daniel Terhorst-North.

You talk about chunking up levels of abstraction and the domain has to make sense at the level of abstraction you're thinking about. And this idea that when you chunk up from different levels of nesting to other levels of nesting within an organization, that there should be I think some form of self-similarity, but this is a really interesting idea that actually...that you can't have that potentially, right?

Software is fractal

Kevlin Henney: It's the simplification. And the way that I guess I've always pitched it is- software is fractal. There's a kind of scale-free...

James Lewis: Right. 

Kevlin Henney: And that's a distinction with many things in the physical world in the sense that we make larger bits of software out of smaller pieces of software and out of smaller pieces. And it's turtles down. Whereas in, you know, I make a building...

James Lewis: But they're elephants.

Kevlin Henney: Exactly. There are elephants for me.

So, you have that kind of idea that there is this self-similarity, which leads to these recursive descriptions. It also leads to challenges to the way we think about our mental models, because we are anchored to the physical world, and we kind of think of things as big and small and all the rest of it, and then are utterly surprised that software doesn't respect that and that, you know.

James Lewis: So, you mentioned fractals. I don't if you know this, but there is fascinating research that talks about the fractal dimension of cities, which is amazing. And you can measure the health of a city by measuring the crinkliness of its boundary, and I wonder whether you can do the same. I've not tried it, but I wonder how you would come up with a mechanism for measuring the fractal dimension of software, essentially.

Kevlin Henney: I think that's an interesting question, because I think there is one that, given that software exists in a very abstract space, this idea of fractional dimensions and kind of that crinkliness is a valid question, and it probably tells us something. If you like, it's the texture of a system and what does that feel like? And it's probably gonna tell us something about the lived experience. What's it like to be a developer in this system? Is it a pleasant experience? Is it habitable?

James Lewis: Is it better or worse, because this is the thing, you know...

Kevlin Henney: It changes over time.

James Lewis: Exactly. You can derive a certain set of other properties from the fractal dimension changing. So, you can say if the fractal dimension of a city, like, decreases, if it becomes less crinkly, then the city is getting sicker if you like.

You know, things like the number wage growth will start to slow and, you know, unemployment starts to go up and things like that start to happen. But you can sort of predict that from the...it's predictive of...the fractal dimension is predictive of those things, which is super interesting. So, I wonder whether, as you say, you know...

Kevlin Henney: Well, given that Adam Tornhill is actually at this conference, so, you know, this is very much his kind of space. But I think that that's an interesting thing because, again, it goes back to this idea of grasping something inherently complex and giving ourselves a view. How can I as a human view and understand something as abstract as a software system with the people working in it, because it's not a kickable solid thing like a chair. How do I understand it? And we are always trying to find the right point of view. Sometimes our perspectives or models work for one era, but they hold us back from the next change.

Recommended talk: A Crystal Ball to Prioritize Technical Debt • Adam Tornhill • GOTO 2017

James Lewis: Right. And coming back to this thing about, you're saying about Rob's work. You know, if you look over time what happens? A classic example regression test. We have to do regression tests because on that day, five years ago, we had a thing happen, so now, we have to do regression. Well, you've got this tiny...it's just an image I'm uploading. "No, we have to do eight weeks of regression tests, right? Because that's what we do now." I think there is that sort of what was suitable for yesterday isn't suitable for today.

Kevlin Henney: It goes back to your organizational thing about the fact that organizations move from... I guess, let me phrase it a different way. They move from value creation, the innovation, they move from value creation to loss aversion, to then how do we keep the thing alive?

And sometimes, I kind of look at that and I wonder if, we're kind of on a pursuit for scaling at the moment, it seems, both in kind of, "Why are you doing microservices?" "Because we're scaling because it's scalable." It's like, "Well, are you scaling?" "No, we're not, but they are scalable." It's like, well, maybe this isn't the solution to your problem. But also, we see this again with methodologies. There's a lot of stuff on, you know, scalable agile, whether it's safe or less or whatever.

And it's just like, well the one I guess I always point out is my son used to do CrossFit and it's just, like, they use the word scaling in CrossFit, and it turns out it has exactly the opposite meaning. When you scale and exercise, you scale down. There's an extra word there up or down in the question.

So, when people say, "We need to scale," they're probably right, but they're probably wrong about the direction. There's an implicit thing there. It's just like, "You maybe you need to scale down, because maybe your problem is not the one you thought it was, and you are making things more complex, and you've ended up dealing with that kind of...you're now feeding the machine." Why does this need to be scaled? "Because we have 100 developers." Yeah, but it's a 20-developer problem.

James Lewis: So, you know, I'm sure you know the author Charlie Stross, Charles Stross.

Kevlin Henney: Yes.

James Lewis: Wonderful. He's one of my favorite authors. Brilliant, brilliant individual. I wonder why we don't have him at more of these conferences actually, but anyway. Maybe we should suggest it.

Kevlin Henney : There we go. This is now on record.

James Lewis: This is now on record. We should get Charlie Stross to come to GOTO to do a keynote. But he's got this lovely, lovely thought that general artificial intelligence is already here. It's just we work on them running their algorithms very slowly.

\I think that's a lovely idea, right, because, in some senses, this is what we're kind of talking about is at some point these things, these companies that we're in, they do take on, then they are greater than the sub, again, complex adaptive systems, greater than the sum of the past, right?

You know, and like, there's another great line from the Santa Fe Institute. I think it was the Second Interplanetary Festival at SFI, which one day I'll go to. That would be like a bucket listing tick. And it's a great quote, which is"If an alien observed earth from orbit, they could be forgiven thinking that cities were the predominant form of life and that humans were the equivalent of their gut."

Kevlin Henney: I think this is... That's a recurring thing, because I know I said them, funny enough, to some friends after my degree. It just like, if you look from orbit, I sai, you know, cities and cars would be...and we are the service role. That idea... And, again, as you say, this AGI kind of view, I think I first read about that idea of, like, the organization, and companies are examples of AGI, from Ted Chiang. Science fiction from Ted Chiang.

It was just, like, it seems to be when we take a step back... And, again, it's that idea you're looking at.

James Lewis: It is taking a step back.

Kevlin Henney: It's just like, well, "Let's just change the scale a bit and see if we see anything else at a different scale." Oh, maybe companies fulfill this role. And that again kind of brings us full circle to why software architecture looks the way it does.

James Lewis: Yes. Yeah, I think so.

Kevlin Henney: And it explains that's an inherent complexity that arises just from the set of moving parts.

James Lewis: I don't know. Maybe this is getting a bit too out there, but we come across the physics perspective on the origin of life, which is that...this is the one which is basically... Sorry.

Kevlin Henney: Is this the David Deutsch stuff? Is this the constructive theory or?

James Lewis: This is not constructive theory. This is the most efficient way to increase entropy is to create life. So, life is a spontaneously created mechanism that more effectively can create entropy essentially, or increase the entropy of a system, so of the system.

So, it's an interesting kind of philosophical idea that the only reason we're here is that we're able to burn calorific content, you know, is...when we're burning calories, we're essentially increasing entropy.

Kevlin Henney: Absolutely. And, so ultimately, there's an interesting thought there. And I guess it's a good place to close in terms of reflection. There's an interesting thought there. Maybe cryptocurrencies and the amount of...maybe that's some kind of epitomey of physics... In other words. That's a generally very good way to turn everything into waste heat.

James Lewis: My most retweeted tweet ever, right, was from years and years ago, and it was a kind of a play on a Charles Stross kind of trope, again, which was so in one of his books "Accelerando," which is the story of a family going through the singularity, the technological singularity.

And in that, they start converting the different solar, you know, planets and the solar system into computronium, he calls it, to run like VMs, right? To run virtual people.

And I wrote when Bitcoin when first started, I tweeted...not first started, but I tweeted something about, you know, we're not gonna be satisfied until half the moon is turned into Bitcoin mines, right? And there is a bit of that going on.

Kevlin Henney: I think you might have underestimated it. You have scary forecasting. And there we go, full circle, back to the tech radar. That's a forecast that may well come true.

Right. Okay. So, there is a lot there to unpack. I hope you've enjoyed this. I certainly have. Thank you very much, James Lewis.

James Lewis: I've had a blast. Thanks, Kevlin.

Kevlin Henney: And please check out James Lewis' talk when it goes online as well. Thank you.