The Goal: Flow Architecture - Micheal Carducci

In this talk, Michael Karduchi discusses the complexities of software architecture and how they relate to AI development. He explains that simply adopting microservices architecture is insufficient without aligning organizational practices and development processes. Drawing from historical insights by Fred Brooks, Karduchi highlights how the introduction of new technologies often fails to yield promised productivity gains due to unforeseen complexities. He emphasizes that AI tools can amplify existing inefficiencies, and that organizations must reorient their systems toward optimizing the flow of value rather than merely increasing output. Karduchi also explores historical parallels in manufacturing, illustrating how similar challenges were faced in that sector and how approaches like the Theory of Constraints can be applied to modern software development to identify and manage bottlenecks effectively.

You mentioned my name is Michael Karduchi. I am a bunch of things. Uh among other things, I like to call myself a holistic software architect. And it sounds high-minded. It sounds like I'm coming up with something clever to differentiate myself, but honestly, the reason I came up with that title was because I didn't know how else to explain the fact that in almost over a decade as

an independent hands-on software architect, whenever I would come on to a client, I come on to a project, most of the work that I did wasn't software architecture. And I always felt weird about that. And then I started to realize some deeper truths that were going on. And one of the biggest things is architecture is great. I'm I'm a fan. But architecture demands certain things that if

you want to, for example, execute at a very high level with microservices as your architecture. It's not enough just to take your application, break it up into a bunch of small pieces. your entire organization has to level up. And so often when I would come in, they said, "Hey, we're we're we built microservices and all of the promises of what it's supposed to give us wasn't showing

up. Why?" I said, "Oh, your architecture is fine. It's everything else around it." And then I would spend a lot of times, a lot of time helping them redefine their SDLC, bringing in new procedures, new tools, new ways of approaching all of this to enable that architecture. And it turns out that this helped me see very clearly some of the challenges that we're having with AI. And

that's why I want to talk about why AI acceleration, despite all the promises, despite all of the hot takes on LinkedIn in so many real world cases, it's slowing us down. And this isn't something new. This isn't something that we didn't see coming. We did see it coming. This old guy right here, it's a guy named Fred Brooks. And he said in 1986, he said, "There is

no single development in either technology or technique which by itself promises even a 10x improvement in productivity." That's really what's going on. This is what he observed in 1986 and what he predicted to be true today. Now, you might look and say, "But we have AI, and AI makes us so much faster. 100,000 lines of code in a month. We're 500x developers. 100 lines of code a

day. Now we write 8,000 lines of code a day. We ship 40." All of these takes. And it's really easy to look at that old guy who said that back in the 80s and say lies. We're all 500x developers right now. But let's look at the reality. the double blind studies where we uh what we think is happening and the what's actually happening. We're slowing The math

ain't mathing. So either Fred Brooks was wrong or the people selling AI are exaggerating just a little bit. Now personally I think that man Fred Brooks was right. Now, at the same time, you hear what he said, and that sounds like something that somebody would vomit up onto a LinkedIn post before they had their coffee, and it would have already traveled all the way around the world.

Just another hot take. But remember, he said that in the 1980s. Now, in the 1980s, there was no LinkedIn, there was no Twitter. for an idea to spread. It didn't just have to be a hot take that generated engagement to juice the algorithm. We had to get these ideas to spread the old-fashioned way. You had to be rigorous. And so this idea earned its virality the hard

way by being vigor by being rigorous. It was amplified by humans rather than algorithms. It was spread through quality rather than engagement. And one of the things he said was there will always be essential complexity. Now the essential complexity of a problem, this is the part of the problem that you're probably solving with software that is inherently hard. The the the details that involve the domain and

everything else, the stuff that's just And then there's the other kind because the essential complexity never goes away. There's nothing that can make it go away. There are certain parts of the problem that are always hard. We can't make it go away. We just move it. And in the process, we often introduce what he describes as accidental complexity. This is the complexity that's not inherent to the

problem. It's a complexity that we just add in ourselves. And we do this all the time, whether it's overengineering or overarchitecting or anything else. And this is kind of what he was talking about in this paper. And that's kind of why the math ain't mathing. We didn't eliminate the complexity. We just moved it somewhere that we're not measuring. So, in my personal opinion, I think uh Fred

Brooks was right. He was ahead of his time. Now, other people might look at that and say, "Well, I don't believe you." You might say, "So, you're telling me there haven't been any major productivity gains since 1986?" Now, if you've been around that long, you'd be like, "Oh, no, it's way different today. We have all these new tools and abstractions and higher level languages and frameworks and

everything that makes us more productive." So, obviously, we can disprove that. Except that's not what Fred Brooks said. What he said was there is no single improvement or single development that promises that even an order of magnitude increase in productivity. And that's what we keep hoping AI is going to do for us and it doesn't. It's a constellation of things, a combination of technologies and techniques and

ideas. a deliberate composition of these things that we put together in the right way to solve the problem. The truth is we're not going to get there by luck uh by rolling the dice which is what we do by the way with the language models at the end of the day. It's very very clever but it's also just generating random numbers to get some token. And the

reality is anytime we introduce an isolated acceleration into a system, it always makes the system as a whole slower. Now, the good news is there's an answer. And it's not as simplistic as the token merchants would have you believe. Bigger models, better prompts, things like that. It's not a silver bullet, which Fred Brooks said in that paper doesn't exist. Instead, it's a way to think about the

problem. And that's what we need more of. AI as a tool is making us think less. And what we need to be doing as stewards of this technology, as the people who are going to guide us into a new era of software development, we need to think. We need to bring what the AI models can't. And in fact, the reason that I'm quoting some guy from the

80s is because we've seen this movie before. And we saw it a long time ago, long before AI. In fact, not even in software development. The problem that we're experiencing right now where if we're 500x developers, why where is our 500x releases? You know, where is the Cambrian explosion of software? It's missing and nobody's talking about it. But we didn't see this just in technology. The first

time we saw it was in manufacturing factories. Now I see you're nodding and I see other people are kind of looking at me squinting. They're like, "Hang on, manufacturing." I know. Bear with me for a moment because imagine you have a factory and you're in charge of it and it's been running for years. It's not perfect, but it's doing okay. Hey, it works. And on your entire

assembly line are human beings operating at human speed. And then there's a new development in Robots, automation, high techch. This is the future. And a whole lot of people said, "Well, what's going to happen to my job? It's got to change. That's what's going to happen." But what we got was parts of the process were more efficient where we were using the robot. We introduced pockets of

automation into the broader system. Faster machines, more automation, higher utilization. And you would think that would speed things up, but what actually happened was the system got slower. Output went down. Output went down. Even though once we introduced those things, people were working harder than ever. We got busier and busier and busier, but we made less progress. So in this case, one station gets faster, but all

of the upstream constraints and all of the downstream constraints, they're still there. So we have local throughput rising, but the system throughput doesn't. And of course, managers, we all have managers, and managers are going to manager, and they're going to they're going to want to seem like they're on the cutting edge. They want to be able to present themselves as thought leaders and come up with big,

bold, piffy headlines on their LinkedIn profile about how they are innovating the future. And their definition of innovation is just issue a mandate. We need to be using the robots more. And this is exactly what happened in the 80s. The mandates came down. They they said, "You need to be running these machines constantly. We just spent a lot of money on these machines and they are way

more efficient than you. So run them 247." And they did this and everything slowed down. Chaos ensued because the math ain't math. So the reality is we didn't just foresee this problem back in the 1980s. We ran headirst into it. But the answer was there. And the answer has been sitting there waiting for us now for 40 years. The answer started with a simple question. What's the

goal? Because the goal is not to make every machine as efficient as possible. The goal isn't to keep everybody busy. The goal isn't to maximize output at every step. The goal is simple. to optimize and maximize the flow of value through the system. And the truth is, as we've seen, when one part I'll throw that back up. Go ahead. The truth is, as we've seen, when one

part of the system speeds up, but the rest of the system can't keep up, we don't get more output. We get what they call inventory. This is all this is the backlog of stuff piling up once it gets past the fast stage before it can get to the slow stage. You get delays, you get the illusion of progress. And so what happened back in the 80s with

manufacturing when we got robots just like we have robots today that can crank out code instead of assemble widgets, we optimize the parts instead of the hole. people studied this. They figured it out. They solved it. They proved it in theory and in practice over and over and over again. And the idea spread in a book called The Goal. Now, this might not be the book you

want to read. You can read it. Uh there are better ones. But but the whole idea came out of a body of work in the 1980s. And the the idea itself was something called the theory of constraints. And I want to talk about theories for a minute because that word doesn't mean what we always think it means as as a as a society. Usually if I have

a guess, I'll say I have a theory, but it's not theory, it's a guess. Maybe it's a hypothesis. Theories are kind of the highest honor a set of ideas can have that it's like this is the best working model that we have right now. the theory of gravity. Like gravity definitely works and we're pretty sure we know how it works. There are things we can't test and

that's why we call it the theory of gravity. This is the theory of constraints. It is not a guess. It's not a hunch. It is a rigorous approach to solving the flow problem. And when this when this book came out, it changed the way we think about systems. Now I'm talking about manufacturing and you might be wondering what does this have to do with software? The answer

quite simply simply is because if you don't know what the goal is then every optimization looks like progress and still somehow that progress doesn't materialize and that's why we can generate more code and somehow still deliver less value. So if the goal is flow what does that mean for the architecture? What does that mean for the teams? What does that mean for DevOps, for AI? It means

we need to stop optimizing for the what and focus on the why. And here's the thing. We already learned this lesson. And I'm not talking about the 80s anymore. We learned this lesson again this century in our industry 20 years ago. Didn't have We learned it 40 years ago. We learned it again 20 years ago. By the way, I'm just going to throw this out there. If

you start paying attention and you stop filtering everything through the lens of what's brand new and cutting edge, you just take one step back, look a little bit at the bigger picture. You see, in our industry, we keep rediscovering the same ideas about every 5 to 10 years, seven on average. And here we are again. 20 years ago, that book inspired the DevOps movement because they started

to see a parallel between the assembly line, having an idea, building it, going through the whole process, testing it, etc., delivering it. And they said that's exactly what we're doing. It's just code instead of widgets. And so this book became the seinal reference for the DevOps movement back in the day. And the thing is, okay, we have DevOps. DevOps today is another buzzword. Microservices, agile, DevOps. These

words don't mean anything anymore because once the idea started to spread, other people are like, "Oh, oh, oh, you have the answer. It's DevOps." Okay. Uh, we need a DevOps. That's that's what your managers are saying. They're like, "Oh, we need a DevOps. We need a DevOps." What? Okay. The same thing happened with agile. You know, if you're if you're old enough to remember when agile first

kind of came around, agile had a lot of great ideas, had a lot of answers, but we didn't care about the why. We didn't care about the how. We just focused on the what. And so, next thing you know, you all get sent to the two-day training and the only thing that really changes is you get your orders standing up now instead of sitting down. But everything

else stays the same. And we saw the same thing with DevOps. Generally, what they said, oh, we need DevOps because that's how we're supposed to do it now. Okay. Well, we have an ops team. We're going to rename them DevOps. And now now, now we're now we have a Manager's got a manager. But it wasn't always a buzz word. It started with a very specific idea. The

same thing we're fighting with right now. Optimize the system. Not just one part, the whole flow. Optimize flow. But like anything as it spread we just kept the what the pipelines the automation standups if you will CI/CD even though most of the people who are like oh yeah yeah or CD CI pipelines most people who say they have CI pipelines for what it's worth and I'm not

going to get into it aren't doing CI a pipeline is not CI continuous integrate a pipeline is a tool to facilitate CI it is not CI in and of itself but we kept the things we checked the boxes is this is checklist leadership. But we forgot the why. We forgot the goal. And when that happens, every improvement makes the system worse. So if the goal is flow,

what determines flow? And the answer surprisingly is not everything. Usually it's just one thing. And in the theory of constraints, you might be able to piece this together. In the theory of constraints, what determines flow? What is the one thing? It's the constraint or the bottleneck. Now, there might be multiple constraints, but we look at the current constraint, the primary constraint, because in any system, there's always

one thing that's going to limit everything else around it. And right now, the limitation is largely centered with people. But as everybody tries to take the people out of the entire process, they get disastrous results. And we've seen this over and over again. But the thing that limits everything else is the constraint. So in the factory, it might be a machine, it might be a station, it

might be a person. It's the thing that everything else ends up waiting on over and over again. And in the 80s when they ran into this problem, what did they do? They tried to optimize everything except the constraint. Everybody got busier. It looked like we were doing something. But when you actually measure the results that matter, not the vanity metrics, not the faux productivity metrics, but the

things that really we realized that everything slowed down. You know, another thing that we learned decades ago, by the way, just as an aside, because this is one of the things that has been quietly driving me crazy, everybody's talking about AI and they're talking about their productivity. What's how how do they point out their productivity? How do they measure it? >> Lines of code. Hey, look how

many lines of code I shipped. You know, that used to be a thing like in the 80s and 90s. You would get paid by the thousand lines of code, the KOC, the clock. All right, we're going to pay you so much money per clock. What happened? Well, we ended up generating more code. I worked for a company and that's how they wanted to measure productivity. They said,

"Okay, we're we're measuring your productivity, Michael, as a developer by lines of code." Uh, by the way, the first thing I need you to do because you're a developer is I need you to write a little a little tool that plugs into my little business dashboard that counts all the lines of code in the codebase. And I said, "Oh, you you you want me to do that?"

Okay. Um, well, how do we measure lines? Line endings. Yeah, sure. Sure. So, what count line endings? The thing is sometimes you have an LF, sometimes you have a CR, sometimes you have a CRLS and I don't want to presume. So I'm going to count CRS separately. I'm going to count LFS separately and also semicolons because sometimes I've got code that's minified. So most lines got counted

three times. And then that was great. Amazing. Already started to look good, but then I needed to keep that rolling. So, the next thing I do, of course, is uh I never delete code because that's going to screw up my metric. There's a there's a there's a there's a reality. There's a one of these piffy apherisms. It's called Goodart's law that when a metric becomes a target,

it stops being a good metric. And this is exactly what happened to us. So, if I had a bunch of dead code that I'd refactored away that I didn't need anymore, if I deleted it, it would screw up my metric. it would it would make my dashboard look like somehow I went backwards. And I did have a manager who was smart enough to understand that that's a

lot of times that's a good thing. So I would take all of that dead code and I would just wrap it with if false. There's your metric. All right, speaking of metrics and code and everything else, let's talk about software because I want to show you why this is true. I want to make it concrete from a systems perspective. So here we are. We have our software

development life cycle. It starts with an idea and we take that idea, we put it into the backlog and then we pull things out of the backlog, we design them, we code them, somebody reviews them, we test them, we QA them and then we deploy them to production. And then of course this starts all over again. new ideas, new backlog items, more design, more code, more review,

more test, deployment. And this it's a pretty picture. Like this is how we think the system works. It looks clean, but it's not quite accurate because between every step there's inventory. And inventory is just the stuff that piles up between stages. So let's look at this a little deeper. what's fast, what's slow, and what's somewhere in the middle. Well, it's easy to come up with ideas. It's

pretty easy to put them into the backlog. Sometimes the bottleneck is prioritization or sometimes the bottleneck is ideation, but let's just pretend it's not. Uh then we actually have to build the feature. The design takes time, the coding takes time, and then there's a manual review process. Now usually we can review code faster than we write it assuming this is all things being equal and humans are

involved but uh it's faster than coding but we've got a bottleneck there and then you know testing the same sort of thing and design and code has been the main bottleneck for ever and the backlog because of that the backlog is usually the first place that things begin to pile up. There's stuff in the backlog, I'm sure, at your company that nobody who still works there even

knows what it's about that there's stuff in there that people added years ago and they're halfbaked ideas and, you know, a cryptic title and nothing else that exists in your backlog and it just it just piles up. This is all the stuff piles up in there. Well, what if we uh rub a little bit of AI into it? Like the problems didn't go away. We didn't clear

the bottleneck. We just moved it and now the bottleneck is over here. Oh, also our review became the new bottleneck because it is a massive problem. I know people every day they say if I have to if I have to go through one more 10,000line PR that I have to sign my name against I'm going to lose my mind. And the thing is, if code generation is

10 times faster, but our review capacity hasn't changed, >> do you just really want all you want to do is 10x the pull request? Is that all we are anymore is manual reviewers? Gosh, I hope not. Do we want to 10x the pull requests or do we want better flow? And it goes back to the question. The question, what is the goal? Because if the goal is

more flow, then sometimes the answer isn't just generate more Sometimes the answer is to generate less, but better aligned, better optimized for the whole endto-end system. In other words, sometimes the best way to speed up the system is to slow parts of it down. And that's what we learned in that book, The Goal. So we we tend to assume that if something gets faster, then the whole

system gets faster. But if that part wasn't the constraint, then all we've done is create more work for the real constraint. So we're here, we've got a backlog there, we've got a backlog there. You know, maybe we're doing the design stuff ourselves. Maybe we're doing the, you know, we got backlog because it takes time to design so we can prompt the AI properly and the AI is

then super fast and then we're slowing down again on the review side. You might reasonably ask the question either you or the manager who has evolved past a we need a DevOps into the oh we just need more AI. Can't we just make everything else faster too? AI is great. Oh, my friend Sam Alman assures me that AI is good for what ails you. Just use AI

for everything. So, let's throw that into the entire process. Right now, we've got a little bit of a bottleneck here. We've got the giant bottleneck here. And this is where all of our inventory piles up right there at at the testing stage because we're letting AI review its own work. And the AI is like, "Looks good to me. Ship it." And then you say, "Uh, this doesn't

even compile." Oh, great catch. Now you're thinking like an engineer. Let me go fix it. There you go. It's fixed. And then you do rounds and rounds and rounds of this. You know, you you've seen this. You've experienced this firsthand. And then it's like, "Oh, it's definitely fixed this time." Uh, did you notice that it still doesn't compile? Oh, good thing your eagle eye is is is

working on this. Let me take one more crack and then it's starting going in loops. This is uh what we run into. But eventually something comes out. It does compile the tests for whatever value the test that the AI generated pass and we deploy it and the business says never We just lost our two biggest customers because we accidentally whatever whatever it is that happened. And all

of a sudden they're like, "Well, we need to regression test everything." And so now your testing takes forever and we're doing this over and over and it's possible that maybe this is doable, right? Maybe we're so fast here that it'll be a net win if we're super slow there, right? Maybe it works out. And it might, sometimes it will. But if we stop there, we miss something

important. This is not a linear assembly line. This whole process is a loop. We don't build software. We change it. That's what 25 years ago, those bunch of guys up in a cabin somewhere who wrote the agile manifesto, that's what they realized. We don't build software, we change it. And so maybe we stop optimizing like it's a oneandone and we start thinking about software as it truly

is because we don't just build software once. Once we build it and it goes out, the customer is like, now that I see it, it's not quite what I wanted or it doesn't quite work the way I hoped it would. So we change it. And then we change the change. And then we change the thing that the change broke. So software delivery software delivery and development is

not a one-way flow of AR artifacts. It is a deeply nested set of change cycles and we need to understand that and realize that and accept that and optimize for it and that's the beautiful thing. And the other thing we have to understand is that every step in software development is really a decision under uncertainty. AI can accelerate the artifact production, but it can't magically eliminate the

It can give you a plausible sounding string of tokens that we can make confident decisions on until you found out that it hallucinated. And that's the thing, that's what Venat was talking about today. Good architecture supports navigating That's a big part of why architecture matters. There's a lot of reasons that architecture matters, but just the uncertainty piece. Let me give you an example. You know, maybe I

take the older architectures that were popular in the 1990s. It was a different world. We would build software that ran and supported an office. It was sat in a server in a basement somewhere. And we knew how many people would be using it, the number of people in that organization. Then one day the world changed. We started building software and delivering it onto the web. And on

that day the whole world could be our customer. But that means we have no idea how many people are going to be using our software. When I started I knew exactly what my scale requirements were always. Today no idea. Like Venet was talking about in the keynote. we think we know and then suddenly it's the fail whale and suddenly that's as far as we can go. So

we can architect for scalability for that uncertain growth or maybe we don't know what the load is going to look like. We don't know if people are going to use it at certain times of the day or if suddenly everybody's going to go on there and everybody's going to leave. We can architect for elasticity. We can architect for evolvability. The uncertainty is we don't know if this

is the perfect software or if this is just going to give us new information to go get closer to the perfect software. So we architect for evolvability. Uh if we're going to be delivering software repeatedly, maybe we architect for testability. These are the characteristics that ar good architecture will induce in the right measure. They're not objectively all good. They're not objectively all bad. It's all trade-offs. So

we need the right set of trade-offs. And the thing is an unsupervised agent cannot make meaningful architecture decisions. It is trained on certain patterns. It's trained on the code that we all privately put into GitHub not realizing that Microsoft was going to buy it and then all of that was going to go and be used to train Copilot. I don't know about y'all, but I have a

lot of private repos in GitHub and most of them are garbage. They're just little halfbaked ideas and hobby projects and things that I threw together and I didn't want to waste my time with That's the training data. That's what these things have been trained on and they're replicating it. But ultimately, architecture is a context problem. The the real world of architecture is so much larger than the

technical requirements or even your non-technical requirements. the context is enormous and most of it has no way of getting into your model's context window. So that's one of the first things that we need to be mindful of. Now one of the second things is AI changes the entire economics of error. Back in the day before Gen AI was what everybody was talking about. Code was expensive and

that meant making big mistakes were expensive. They took time to make. And when code is cheap, making mistakes gets cheaper. When coding is faster, we can make mistakes faster. Which means that today we can manufacture bad decisions at an industrial scale. And even we if we throw in the supervisory agents, they can catch certain things. But the whole model is probabilistic. And the best models with the

best context and the best rag and the best still make mistakes 5 to 10% of the time, 90 to 95% accuracy rate. Imagine you're an architect for a minute and you go to the business, you say, "Hey, look what I built." They said, "How's availability?" We have one nine of availability. You would lose your job. One nine. Nothing has a 1 nine SLA. Usually it's three or

four or five. And now when you think about how these models actually reason, quote unquote reason, they're not reasoning, but that's a different conversation for a different day. That means one step rolls the dice and it rolls a natural one that propagates through the entire reasoning chain. Your stack of agents becomes a compounding error machine. you get cumulative error rates and no matter how many agents you

stack on top of each other at the end of the day somebody some owns that change like this has been making the rounds for as long as I can remember and it only ever becomes more true a computer cannot be held accountable which but the thing is accountability doesn't go away we can't automate that somebody has to take the blame somebody has to take the fall and

companies are feeling this. Amazon, a company that does tens of millions of dollars in in uh in revenue per second, just had like a six or an eight hour outage. Amazon.com, add that up for a moment. Let's assume it's $7 million a second in terms of checkouts. Multiply that by 60. Multiply that by 60. Multiply that by eight. I I I'm too jet-lagged to do the math.

Y'all are smarter than me. It's a big number. And uh what did they do? They brought humans back into the loop. Senior engineers have to sign off on all AI code. And now you have all the accountability and none of the authority. And now you're trying to make sense of the model that just said, "Hey, you know what I decided to do? Instead of just adding that

one little feature in there, I just regenerated everything for you." So it's 100,000 lines and you know, sign off on it and if you miss something, it's you like that's the insanity that we live live in. And that's what happens. Accountability doesn't go away. It gets pushed back onto the humans and usually only when the blast radius is bigger. This is why companies are now regression testing

the entire system every single time. But the third thing that I want to point out, that flow that I showed you, that's not a complete picture. Your system and your SDLC is way more complicated than a PowerPoint slide. Let's be real. This is a nice picture. Reality always more complicated. There's always going to be bottlenecks that aren't visible. So, the diagram leaves a lot out. It's the

stuff and most importantly the stuff it leaves out is the stuff that your agent can't see. And that's that can be dependencies not just in the code but outside of the code. Team dependencies, shared services, environmental drift, policy constraints, coordination overhead. These are more of those dependencies that are invisible. Decision latency, uh human emotion, fear rework the human beings in general. So we're amplifying the coordination cost

because as coding gets cheaper, the coordination just gets more expensive. So if everybody if if AI is giving us all the output of five developers, but the system doesn't evolve, then the organization has the same review capacity, the same testing capacity, the same deployment capacity, and the shared understanding of maybe one developer if they're paying attention. And if that's the case, if that's where you are, you

didn't speed up the system. You multiplied the coordination problem. seems like you're you're with me. You're following along. I'm seeing a lot of nods. I'm seeing a lot of Okay. Uh occasionally you're laughing at my jokes, and I appreciate it. Um because I promise you, they don't get any funnier. I I I know my limitations. I'm not a funny guy. We've diagnosed the problem. We've seen the

system break. what do we do? What does the theory of constraints actually tell us to do? Because the theory of constraints isn't just a theory, it's a playbook. And that's why this book was enormously successful, like insanely successful. Um, so how do we do this practically? It's not another framework. It's not another hottake. It's a way to actually intervene in the system. And one of the first

things we have to do is find the constraint. Everything starts here because if you don't know what's limiting flow, nothing else matters. That's the most important thing that we have to do. That's the story that's in the book and these are the the takeaways that we have to have. And the next thing we do is align the rest of the system around it. That doesn't mean optimize

everything. It doesn't mean go faster everywhere. It means adjust the system around the thing that matters. And you know what Amazon discovered at enormous cost? The thing that matters is you. The thing that matters is us. And you have to remember that because if you're feeling lost, just remember, we've seen this movie before. The truth about AI. AI is new. AI Well, AI is sort of new.

AI is actually 70 years old if you're counting, but we all got excited recently. And so now we're all paying attention. So it's all new to most people in the world. But the problems that we're experiencing, we're connecting to AI. We're like, "Oh yeah, we brought in AI and then these problems showed up." I got news for you. Those problems aren't new. They were always there. it

just at the speed that we were moving we could manage like and I think that's maybe one of the most important things to realize right now in this age of AI AI is not an accelerator it's an amplifier so whatever you're doing well it'll amplify it whatever you're doing badly it will amplify it and there's so much in the industry that we just got used too. Releases

have always been a pain. We're used to that and now they're a train wreck. Testing was always a pain. Now it's a train wreck. PRs were always a pain. Now it's a train wreck. And the thing is we didn't feel it acutely enough to do something then. AI just made it made us feel it in a way that we can no longer ignored. And because all those

problems have already existed, people have been paying attention. People have been developing great ways to address these things. We've been building little islands of wisdom for the last 25 years. DevOps was one of them. DevOps was all about improving flow and it worked at least in the software development side of things. Another discovery we made surrounded coordination cost and communication and understanding the boundaries and the seams

in our system. And for a small number of people, we adopted it and got great results. But for the majority, we just kind of ignored it because we didn't feel the problem sharp enough. And that was domain driven design, the infamous blue book. Uh, another one is just how teams DDD taught us a lot about how to structure our teams in terms of aligning your entire org

chart around flow, around architecture. It was the answer to a problem that was identified in 1967. Conway's law 67 68 somewhere around 67. Thank you. It was the it was the answer to a question that we've been pondering for decades and Eric Evans gave it to us in domain driven design. It taught us certain things and we realized that that makes sense in this context. But there

are other lessons to learn as well. Team topologies was a great book about how to optimize teams for certain flows. I want to talk about some of these things. Another one was extreme programming. Now, I can't decide if this is my favorite or least favorite picture in any slide deck I I have ever presented anywhere in the world. Uh the reason is I am a skydiver. I'm

a licensed skydiver. I've I I mean, I'm not like a massive skydiver. I have about 300ish skydives. Um I even jumped out at 30,000 ft once with oxygen and everything else. I had a video go viral. It got picked up by the BBC because I did a card trick in freef fall once, but um, that's not a picture of me obviously and I'm mad about that because

I would like it to be a picture of me. The problem is my friends know me too well and I'd say, "Hey, you have an old laptop I could borrow?" They're like, "Yeah, wait a minute. You're not going to take this skydiving, are you?" I'm like, "No, yeah, maybe, but I'll hold on to it. It'll probably be okay. And the thing is, I could get a broken

laptop. I get a broken laptop. That's easy. But I don't want to just pose for a picture. That just feels fake. I want to actually jump out of the plane and write a program on the way down for two reasons. One, like like bragging rights, sure. But two, I think the jokes would be amazing, right? You get out there, you jump out, you're frantically typing something out,

and then you your uh audible altimeter starts going off in your ear. It's like, uh, you're getting pretty close to the ground there, Carduchi. And so you look your altimeter like, oh, okay. So you wave off, you deploy your parachute, and then the the force of the of the the the G-Shock of the parachute deploying. You drop the laptop and, well, I hope nobody's walking around down

there. You just watch that laptop disappear and you got your parachute and you fly it. You land it and all my nerd friends are on the ground. They're like, "Okay, Michael, how'd it go? Did it work? Hit a run. It crashed. Right. See, the jokes write themselves. Are you going to try it again? Well, I'm going to have to defragment my hard drive first. What program did

you write? Hello world. Right. Yeah, I told you it didn't get any But uh anyway, extreme programming. Terrible title, by the way. A set of ideas introduced by Kent Beck. It was just the question. And Kent Beck was there in the '9s with a team and he just kept asking what is the goal? How do we optimize flow we adopted none of these things because we love

labels more than we love logic. We love being able to check the box rather than doing the work. We turned them into tribes. Oh, I'm on the DevOps tribe. You're on the DDD tribe. I'm on the XP tribe. I'm on the whoever. But underneath all of these things was the same question. What is the goal? XP reduces the cost of local feedback. It addresses a bottleneck. DevOps

reduces the cost of deployment and operational learning. It addresses a bottleneck. DDD reduces the semantic and coordination friction. In other words, it addresses a bottleneck. Team topologies reduces organizational drag. It addresses a bottleneck. and architecture determines what kind of flow is possible at all. They're addressing bottlenecks, but they were just little bottlenecks back in those days and now they're enormous. So to kind of bring all of

this home, if you would uh allow me to introduce or maybe reintroduce some of these ideas, these are the things that you can bring back. If you're worried about, well, I don't know, I used to be a coder and now I don't do the code anymore. You're not done. It's just an invitation to step up and move up the value chain. That's all it is. And thinking

like this and bringing solutions like this is exactly how you move up the value chain. So, I'm going to reintroduce some of these tools. XP is actually a fantastic case study. I don't know if Kent Beck read the goal. I don't know if he was thinking about the theory of constraints, but he nailed it. And one of them was the constraint around the ideas going to production,

making sure we had the right ideas to begin with. Everybody's in the same room. It it addresses the communication coordination bottleneck including the customer. How long does it take to get feedback on a feature? Well, we we put it in the backlog. We have we we play planning poker or whatever. We we estimate it. We develop it. We ship it. And then six weeks later, we get

some feedback back. And then we find out if that story, the way we implemented or what the idea was was any good or not. And XP, you're working away. You got you got a little bit of the UI. You just say, "Hey customer, what do you think of that?" Now, usually it's not the customer. It's maybe the customer's represent representative today would be a very good product

manager or product owner, but they're all in the room and you're getting that feedback in real time constantly. They're doing pair programming. That's if reviewing is the And we're doing pair program. We're doing real pair programming, by the way, not the thing that we call like there's so many things in our industry we hear the name and we're like, "Oh, intuitively I think I know what that

means." Pair programming that just means uh one developer for the price of two. A developer with an audience. That's not how I pair program. I do what uh the the guy who taught me was a guy named Llewellyn Falco and he calls it strong style paired programming and that uses the driver navigator paradigm. The driver is the person at the keyboard. Their job is to type. End

of list. The navigator is the person who is not in front of the keyboard. Their job is to program. In other words, for an idea to get from my head into that computer, it has to go through somebody else's hands. And we switch regularly. We have different techniques for when to switch and things like that. But you're getting real time review. Sometimes the na the driver is

going to say, "Oh, that's wrong. We need to do it this way." Uh, golden rule of strong style pair programming, no thinking at the keyboard. We switch. And now that person becomes a navigator and I become the driver. That's how I program today. Like I know we can do things faster. I know I can get a stack of Claude code agents and give them a markdown file

and let them run and hope that somebody somewhere doesn't slip one malicious instruction into that markdown file that causes it to go steal my bank credentials because that happens all the time. But I do that kind of pair programming with the agent. It's slower, but it's more durable and I get better flow. I get consistent flow. And when the AI goes off the rails, we switch. Now

we're in ask mode in review mode and I do it. And you know what? It's very easy for me to pick up that thread because I've been part of this process the whole time. I understand that code. The the the it it this exploits some some bottlenecks and some of the bottlenecks become subservient. Another one is work in small batches. This is brilliant. There's a lot of

connections in there. Small batches reduces our inventory. It reduces the the the pileup. It improves flow. Continuous integration was another idea of it grew out of XP. We're all committing to main at least once a day. We're integrating our code continuously, not at the end of a long live feature branch. Continuously test driven development, like real test-driven development, not maybe test after code. MTAC, that was my

flavor for a long time. Maybe I'll test after code. Test- driven development changes the entire dynamic. And maybe you've done this like and I've done this. I'm not I'm not pretending I'm perfect. I'm not pretending that I always do the right thing. I'm I'm lazier than most people and sometimes I just want to play with it. I just want to explore an idea and I don't want

to be all rigorous about it and then suddenly it all works. It all looks good and I'm like, "Oh, I didn't do any tests. Hey AI, generate some tests for me." I will get some tests. That will happen. That's about all that happens. Sometimes I get good tests every now and again. It surprises me and one of the tests fails. I was like, "Oh, oh, they must

have generated the test wrong." No, no, I was wrong. That was me. That's on me. But, um, if but if you think that approach is working great, you probably haven't done it very long. But, you're also losing the value that this practice was bringing in. You know, XP gave us faster feedback, less rework. And the thing is, some of these things that I'm talking about, they will

slow you down. They feel like new bottlenecks. But the these weren't constraints on developers. They were constraints on the system designed to protect flow. These aren't just disciplines or ceremonies that we do blindly because some um guy at a conference said you should. We're doing it because we're doing it in pursuit of the goal. We're designing this the system for for flow. So the theory of constraints

doesn't tell you to make bottlenecks. It just tells you to stop pretending that they don't exist. And then when you find the bottleneck, your job isn't to make everything else faster. Your job is to make sure the bottleneck is doing the most important work. There is a lot of work that we do that isn't important anymore. But that doesn't mean that we are not important anymore. It

means that we need to focus on the most important work and optimize the system around that without interruption, without noise, and without being overwhelmed. So, in a nutshell, find the bottleneck, make sure it's doing the right work, stop everything else from making its job harder, and if it's still the bottleneck, then we make it better. And XP gave us a lot of tools for that. And give

you a minute to take a picture of that slide. All right. Oh, now everybody's going for it. Okay, we'll just chat amongst I can put these slides online, too, if you want. You can just grab them. >> Yeah. >> All right. I'll I'll I should for the rest of my talks, I'll put a QR code at the end so you can grab those. But at the same

time, I do this, too. Even when I download the slides, it's like the pictures that I put in my my photo album because I'm like, "This is really insightful and I don't want to forget it." So, I put in my photo album and I forget all about it. I uh I have so many pictures I've never gone back through. So, now I have an agent that goes

through and says, "Hey, here's some pictures of slides that you've taken over the years. Uh maybe these are still relevant. Yeah, exactly. It's just inventory. You're absolutely right. Well, ah, bravo. You win. You win the talk today. But it means letting the bottleneck influence the system. That's important. And we still haven't explored all the constraints because like I said, there's a lot of things in the diagram

and some of these other tools and techniques help. Domain driven design. We can talk about that for a little bit. See, DDD solves some of the problems that were always there. Now, a lot of people, like I said, didn't pay attention because the problems were quiet. Well, AI is amplifying that, too. What does DDD address? One of them is the understanding bottleneck. Now, this doesn't show up

in my diagram. It's harder to measure. You end up in a situation where nothing is obviously broken, but everything is slow. And we're just talking about words here because it's not always the code. Sometimes it's meaning. And this is where probabilistic language models go off the rails because they are only always guessing at meaning. And DDD pointed out that hey, you know what? Humans do that too

and we make mistakes. So maybe we should be explicit about the words we use and what they mean because concepts drift, interpretations change even in the same organization. You have one department, they have something called a product. So maybe you've got an object called a product. What's what what's a product? Maybe it's something that sits on a shelf and has a price and a skew and a

vendor and whatever. But in the finance department, a product might be a credit product. Net30, net 60, net 90, something like that. And in another department, a product means something That was a really important thing that uh domain driven design figured out that every constraint costs time and misunderstanding costs rework. So we got this concept of the ubiquitous language. there was one language shared across the dev

and business within, you know, a and there's no translation layer. There's no guessing. We're all aligned on what we mean. Uh because the translation was latency and now it's risk. Um but the thing is we're diverging at organization scale and that's why DDD gives us bound bounded contexts. These are these are these allow us to define boundaries to control this me the scope of meaning to reduce

the cross team ambiguity and keep team effort cohesive and that has big implications because without boundaries the coordination explodes and we're feeling this. This is one of the things that's not in our diagram. We have aggregates that control consistency and define transaction boundaries. Uh this reduces coupling, reduces coordination. By the way, if you're going to if you want to read on DDD, Eric Evans's book, admittedly, is

is the book uh I never finished it. I found it too hard to read. I even met Eric Evans and I admitted to this to him and they all laughed. They said, "I read it wrong and I said, "Okay, I guess I read it front to back. I'm supposed to jump around." Uh Von Vernon has some better books. DDD distilled is a good place to start. We

have context maps where we actually start to map out the relationships. We're actually measuring now. We're actually visualizing the stuff that was hard to see. We have less ambiguity, fewer conversations, faster decisions, better flow. That's what we're doing. This is what's changing. It attacks the invisible constraints. It's not just modeling. It's system design. Team topologies uh handle some different aspects of coordination because the theory of constraints

is all about making sure that the constraint focused on is doing the most important work and we can do more to build robust system and elevate the constraints because we know more teams means more dependencies, more communication, more bottlenecks and the team topologies isn't about org charts. It's about the flow of change through teams. We're not organizing people. We're designing how change moves through the system. So

we want to optimize team interactions. That's one of the core ideas of the book and we can apply it to system thinking about flow. So we want interactions not structure because it's the bottleneck is not how the teams are arranged, it's how they communicate with each other. It's how they depend on each other. And that unstructured interaction just makes everyone depend on everyone else. And that's another

pileup. That's another constraint that doesn't show up in our pretty little picture. It's an invisible bottleneck as the worst kind. It's not a queue. It's not a dashboard. it's just everything taking longer. Uh so we want to design teams around flow and the book encouraged us to think about units of interaction which gives us four team types. One is the stream aligned. These are the the flow

the main flow of value. We get requirements. We build it. We deliver it for the customer. Right? That's they own a flow of change. They own end to-end responsibility. They're designed to minimize coordination. And this is one of the best cases of microservices where a team owns a microser and they can kind of do all their stuff completely independently without depending on the other teams. That's if

you're doing it right. Most people don't do microservices like that. That's what Venat was talking about this morning. But this is the main flow delivering enduser value. We have platform teams that exist to remove friction. They don't centralize control. They make the common path fast and safe. We have enabling teams and their job is just to unblock constraints, transfer knowledge. They're temporary by design. They don't own

the flow. They just improve it. And then we have complicated subsystems teams. They're the ones that isolate complexity. They protect the system. When you have something that's inherently complex, we can isolate it so the rest of the system can say stay simple. So, it's all about macro flow where we're architecting the interaction modes. Now, the hard truth of all of this is that sometimes we have to

slow that down to improve flow. And it's not discipline. It's not ceremony. It's just goal was never lines of code. The goal was flow because there is no even 10x improvement in productivity. It's a deliberate composition. There's no recipes. Nobody can tell you what you should do next except maybe you. And I know the Spanish Inquisition did not expect that. But we are out of time. And

with that, I will say thank you. [music]