 So we have Michael Feathers, the legend himself, at least for me, reading his book about working effectively with Legacy Court was such a refresher and it was a mind-blowing experience and having known Michael for a few years now, we were just talking backstage that me and Michael could spend hours talking about all kinds of things such a such a deep thinker and influencer in the agile community and in the teen code community. So Michael, it's a real honor to have you with us and talk about, you know, your net positive development thought process. So greatly appreciate you joining us today from California and without much delay, I want to hand it over to Michael. So yeah, if you could please go ahead and present your screen. Okay, so I hit camera and then present. Present first. Yeah. Okay, present. Okay. And then go to this. Hang on, I think you need to turn your camera on, sorry. Okay, so I'm going to switch back. Okay, so. And while you're there, you could just hide that thing on the bottom as well. Right. Perfect. Okay, is that good? Awesome. Yeah, I think you're all set. Great. Well, I'd like to thank everybody that's attending. It's really kind of interesting and cool to go and do a conference from California all the way, you know, broadcast across Agile India. And yeah, so the thing I want to go and talk to you about today is something I'm calling net positive development. Best way to go and describe this. It seems like there are many different ways of going and looking at problems and looking at situations that we approach in the world, and particularly for us, as like systems designers, it's valuable to go and find certain frames that kind of give us a lot of benefit. And what this talk is about really is really kind of using like the science of networks and graph theory to go and basically develop a frame for understanding different social phenomena and different code phenomena that we encounter all the time in design. So I'm going to kind of like walk through a series of different things and different situations and show you, you know, how some of the tensions that we have in networks really kind of like apply both in the social realm and also in the technological realm. And I think what's interesting to me about this is that the fact that we don't do this as much basically leads us to go and sort of like arrive at solutions, which might not be the best in certain circumstances. So I just want to kind of jump ahead here and just kind of talk about graphs. Okay. It really I guess depends upon where you go to school or how you learn computer science, how much you actually might know about graphs and graph theory. But you know, the notion of graph is really fundamental within computer science. It's really the notion that we can model many systems as nodes and edges. Okay. So nodes are just basically points that represent things. And edges are basically things that are relationships between the different points. And, you know, again, you can model just about anything using graphs. And one more common things that we model using graphs are like networks, for instance, like, you know, the telecommunications networks that we deal with all the time. But you can you can model like word usage, you can model relationships, you can model, you know, organizational structure, you can model structured entities within code. The history of graphs, though, is kind of fascinating. Graph theory is basically pretty much assumed to have started with a particular problem called the Kernesburg bridge problem. And this was something that essentially the mathematician oiler solved a long time ago, centuries ago. The idea behind this problem was essentially you have this particular particular layout of rivers and bridges within the city of Kernesburg. And the idea was to basically see if you can travel from a complete path going and crossing the rivers using these bridges without ever taking a particular bridge twice. And what oiler basically did was he sort of said, okay, look, we can have the pictorial representation of this problem where you can actually see the rivers and the bridges here. We can also go and basically sort of like just sort of map it out with a simple notation of nodes and edges. And then with that, start to go and see the problem in a rather abstract way. And once we see it abstractly, we can go and basically sort of like try to go and apply some mathematical machinery in order to basically figure out whether that particular problem is solvable or not. From those humble beginnings, graph theory has kind of grown into a very huge discipline. And it's really at the basis of topology in a bunch of other areas of mathematics. The way that it kind of intersects with computer science, though, is kind of interesting. You might have heard of Dijkstra, Edgar Dijkstra, who basically was one of the earliest computer scientists. He basically specialized in creating algorithms for graph theoretic problems. And one of the key contributions he made is something which still buries his name, Dijkstra's algorithm. And it's really all about finding shortest paths and graphs. And you can see here that essentially we have different numbers for the nodes, like the top one is five, and we have six, three, and four. But the thing is that also within graphs, you can basically assign weights to the edges, and there are numbers that basically represent these particular weights. He was able to go and basically find this nice algorithm which very simply and cleanly can find in any graph the shortest path between any particular nodes that you happen to have. And yeah, so Dijkstra himself, he was a physicist by training. And it seemed like what happened within the early computer science community was that there were many people who were kind of like came on exodus from physics. There was like a glut of physicists back after World War II in the US and around Europe. And they basically needed something to do because a lot of the nuclear programs were winding down. So they basically moved into the nascent field of computer science and started basically applying mathematical tools that they had to problems in computer science. So Dijkstra was an interesting guy, quite a character. Beyond his work though, it seemed that a lot of the hotbed for computer science research was really in places like AT&T Bell Labs. Dijkstra never worked there, but the thing that's fascinating is that most of the early applied work that was ever done in graph theory and things like combinatorics really kind of occurred at Bell Labs because they had essentially network problems. They had to basically figure out routing of things and very different complicated problems that we never really had kind of like confronted before within the context of engineering. So that formed the basis of a lot of the work that we do. But you know, the thing is like, what about today? You know, where do we actually go and use networks and graph theory to go and solve problems? And how do we actually use them to understand the world? Well, I want to come and take a little bit of a segue into scaling first so we can kind of talk about that and how you can see different things as graphs and as networks and sort of solve problems that way. An interesting thing that we're going through right now in agile software development is the issue of how do we scale up teams and organizations. And I'm sure you're aware of the skill of agile framework and various different ways of going in and sort of like orienting organizations for like maximal software delivery and stuff like this. But the big question is like, why are those things so complicated? Especially when we kind of started out with like things like extreme programming where you basically had a process that was like good for maybe six to eight people working together to go and deliver software. Right now we're basically, you know, in this space where we're basically doing, you know, you know, we're doing all sorts of things like the less process and we're doing like Spotify model and things like this, figuring out how to basically maximally organize ourselves in order to go and solve the problem of software development. But it's quite amazing to consider there are so many different moving pieces and something like this relative to the simple thing you can do it like a much lower scale. And I think we just basically don't really spend enough time thinking about why the problem gets harder as we get bigger. Okay. So let's talk about that a little bit, right? Scaling in general, you know, we've moved from say model list to microservices, right? So instead of having one big hulking mass, a big thing that we're working on, we try to break it up into many, many small pieces. And that's just basic modularity. But we find ourselves doing this in software architecture, after a long time of trying to go and basically build these huge monolithic things. Now we're basically going and trying to go and build smaller things we interconnect in order to go and solve problems. For scaling, it's kind of interesting to go and notice that this problem of scale and how things change as they scale is, you know, just like the underlying basis of so much of what we do. And I think a way to go and kind of like see it in sharper leaf is to kind of look at science fiction. So here's like a still picture from an early 19, you know, early science fiction from the 1950s, 1954, right? And this particular trope has been used across science fiction for decades that you have some creature that we're basically used to seeing like an insect, which is like, you know, very small, grows to like this huge size and just becomes this monster that everybody goes and has to deal with. But we all kind of know in our hearts that this is not possible and it's not really true. And the reason why we can't have insects at like such large scale is really down to physics. Okay, here's a piece of an essay called on being the right size from 1926. Insects being so small do not have oxygen carrying carrying blood strains. A little oxygen, their cells require is absorbed by simple diffusion of air through their bodies. But being larger means an animal must take on complicated oxygen pumping and distributing systems to reach all the cells. In other words, as things grow, their structure has to change. Now, this is, you know, basically holding basically going and explaining this here, but he's not saying why at all. The real reason why structure has to change as we scale is something that basically Galileo discovered, you know, centuries ago. He basically articulated something that's now known as the square cube law, or sometimes just basically known as Galileo scale scaling law. He basically said that as things grow, essentially, the volume grows faster than the surface area of the thing that's growing. Okay. So for instance, if an elephant is growing, it's kind of like, you know, its volume grows as the cube of n, whereas its surface area grows as the square of n. And you might say, okay, well, who cares? Why is that a big deal? But the fact of the matter is with that increased volume is increased weight. Standing in relation to gravity basically means that a lot of the internal structures and the external structures of the elephant have to grow in a particular way to go and basically make, you know, the elephant, you know, possible, right? You simply couldn't take a mouse and grow to the size of an elephant without it kind of like collapsing, you know, into a puddle of blood really, because it doesn't really have the bone structure or the organ structure or anything that's necessary to support the weight of being at that volume at that size. Now, it's not just biology, though, that has this constraint. If you look at buildings as well, you can't take a little hut or a little cottage and basically grow to the size of a skyscraper without changing materials or changing the building technique, because essentially there's this relationship between the growth of volume, which is n cubed, and the growth of surface area, which is n squared. And because of the way that this happens in geometry, things have to change structure as they scale. Now, you might look at this and go and say, well, gee, you know, why is that, you know, why is that relevant to us in software? But we'll talk about that a bit more as we go forward. So yeah, can anything scale without different structure? You know, as I said, physical structure basically has its own constraints like this. But is that true of like, say, network structure, like the structure of social systems and the structure of like communication pass across an object oriented design or microservice design? Well, let's look a little bit further. Okay, so there's that tension between n cubed and n squared. And we can look at how structure grows now, what about. So let's assume that we have an organization. And in this organization, we have all these people that have communication pass between them because they're, you know, they basically need to go and carry on and do their work. One of the things that we kind of learned from cognitive science is the notion of Dunbar's number that it seems that human beings are kind of tuned to go and have no more than about 150 relationships within a context. Once you go past like knowing 150 people in an organization, it's kind of like you, you basically no longer recognize people by site or by name. And it really has to do with like the brain, the way our brains evolved. We kind of evolved to basically handle communication in relatively small groups of people around 150. And this was first made as an observation by an organizational theorist, Robin Dunbar. But also there's a lot of empirical support for this, that we really have trouble going and scaling beyond 150 people. And it's interesting to kind of notice that, you know, as we're trying to grow, you know, software development teams and software development organizations, we encounter that same thing. It's also kind of well known that basically when you have a startup, if you once you get past about 150 people, you definitely have to change organizational structure to basically be efficient enough to actually do the work that you need to do. So there's that aspect of things as well. So social systems have limitations like this as well. Fred Brooks, okay, wrote this book, The Mythical Man Month, decades ago. And one of it, one of the things that he kind of pointed out was something that's now known as Brooks law, which is that essentially as if you have a late project, if you add people to it, it becomes later. And the corollary to this, the way that he kind of like sort of like articulated this was to point out that when you have n people working on a team, they're actually like about n squared communication paths between those n people. And it's kind of like, as you add more people to that team, you know, n squared is going to grow much faster than n does. So not only by adding people, do you have more people, but you have more possible communication paths. And when you have more communication paths, things can slow down because there's more work involved in developing consensus. As an example of this sort of thing, just imagine the scenario that you happen to be out with a group of friends, if you have like three friends and you're trying to decide where to go to dinner, it's pretty easy. If you have 15 friends, it gets really kind of weird because you have a lot of work to do to basically figure out everybody's really on board with where you want to go out to dinner. And this consensus problem is really just a very common thing that happens in software development teams as teams grow, developing consensus and basically getting all the feedback and input that you need to make decisions effectively across that team tends to grow as well. So there is this thing where basically we have trouble scaling teams. Let's look at this in a graph theory point of view as I was mentioning a little bit earlier. Here's a fully connected graph. We have nodes and edges, and you'll notice that every single one of the nodes is connected to every single one of the paths. So it's n squared, n squared pass and n nodes. Now, it's kind of interesting with this. If there's a cost to going and basically having communication between each one of these nodes, then what happens if we try to reduce costs of it? Well, one thing we can do is we can still keep the graph connected by removing some edges. Okay? So I've removed some edges, but still there's a way to go and get from every node to every node, even if you have to go through another node. So I'm going to go back for a second. This is fully connected. And this is a graph that's just connected, meaning you can always get from one node to another, even if you have to go through other nodes. What does this look like? It's kind of a hierarchy in a way, isn't it? It's kind of like you have this one node, which is carrying a lot of communication costs, and essentially to talk to your coworker, you have to go through this hub. It's almost like having an organization where you have separate divisions, and then you have like the CEO that basically you go through to communicate, you know, rather than communicating laterally, we're basically having a manager to separate people that don't talk to each other. So this is kind of like the hierarchy problem. And we've basically been trying to solve the hierarchy problem in Agile for decades now, right? Going and saying disintermediate, basically don't have team leads, all these things in order to go and actually have more peer-like communication. But the thing about this is that there is a cost to having more interconnection within teams. So there's a natural tendency to move towards this as we're trying to remove the cost of communication. And, you know, it's weird about this to just go and say that this right here is better, because the thing is, as it grows, as you have more and more nodes, at some point, it becomes unwieldy. So you really have a choice between having small teams that basically have great culture and a lot of intercommunication and having bigger teams where you're almost obliged to go and form hierarchy, just because of the network dynamics. So I think it's an interesting thing for us to kind of recognize within Agile that when you see hierarchical structure in organizations, it's not necessarily because people are trying to be evil or something like that, it's just basically a natural response to forces of trying to minimize or trying to sort of like prevent slowdowns and basically sort of minimize communication overhead within teams and organizations. And this is, again, something we can see through graph theory and network dynamics. So, yeah, there's a big difference between these two graphs, but there's a natural tendency to move towards the one that's on the right. Now, an interesting thing about this too is that in some organizations that try to be very flat and yet still have separate teams, it's interesting to notice that there's almost like this natural tendency towards having people that are acting as gatekeepers or managers. A friend of mine told me this story once that basically he was working on a team and they were all peers on that team, but they were having trouble because they were really getting tired of having meetings with the product people. So they'd actually get together several times a week and then it was kind of like all of them and sitting in a room. The conversations became a bit tedious, but what they did is developers, they hired another developer who basically was a manager previously and he actually enjoyed going to meetings and they thought this was a great solution because then he could go to the meetings and they could basically just go and kind of like stay away. So it seems like a little bit of a lazy solution in a way, but the thing that's kind of fascinating about what happened with this is that that one developer kept going to the meetings and meeting with the product people and then what happened then is that in meeting with the product people, the product people would say, hey, can the developers do this? And that developer would run back to the development team and go and say, well, yeah, can you do this? They'd say, oh, yeah, I guess we can and then he'd run back. And the product people started getting frustrated because they said every time we want to go and sort of get a commitment, we've got to go and tell it to you and then you've got to go and run back to the team and get it and come back to us. So it's really like this kind of crazy situation. And you can easily imagine a situation where at some point that developer would start just saying, yeah, sure, they can do it and then just go back and start telling them that they had to do it. So there's almost like this way in which because of the dynamics of situation, you almost start to evolve managers, evolve them from just like the natural state of the system that because you want to kind of like reduce the number of meetings, some people will take on this hubbush role and then start to go and actually act as mediators. And that's just part of the dynamics of what we have is we scale things up in organizations. So it's interesting with this that there really is like this tension between excuse me, n squared and n, much like with the Galileo scaling law, we have a tension between n cubed and n squared. When I'm talking about n squared and n, it's kind of like this is a fully connected graph on the left, which is really n squared, you know, connections. The one on the right is really more closer to n. It's kind of like, excuse me, we have, we have like six, you know, six nodes and we've had basically like five connections between them. So as these things grow up, these two different schemes, you know, it's kind of like as you fully connect, you have n squared and as you basically use this tree like spanning structure, you have something which is closer to n. So yeah, there's tension between those two things and much the same way that we have tension between volume and surface area and physical systems. And most everything that we deal with in terms of scaling systems is about going and dealing with this tension. Let's look at something else. Anybody know what this is at all? I guess I'll just kind of like tell you this is really like an airport routing map, okay, for an airline. And you can see that essentially most of the flights seem to kind of like go in and out of Atlanta, which is that big cluster that we have in the lower right hand side of this map. And we have a couple of other clusters in different areas of the map. This is really a natural thing that happens across many systems. This is kind of like called power law networks or kind of like a skill free network. It turns out that for economic reasons, it's really kind of hard to have a fully connected graph among all the airports in say a country, for instance, you know, going and having like direct flights from say Dallas to Phoenix doesn't give you as much benefit as going and routing through an existing hub. So if you're looking at basically going and sort of like figuring out where you want your airline to fly to, it's much more valuable to fly to hubs to basically go and have like lots of flights going out from them, because then the people that are coming on your flight can basically go to many, many different destinations. So this kind of a network evolves in many systems where there's like competition in a way or where there's an advantage to basically going and connecting with something that already has value. And you'll see this also in things like income distribution, for instance, okay, inside countries, for instance, it tends to be the case that if people are rich, they tend to go and get richer. And quite often you can look at this as being a the result of corruption and things like this. And often it is, but sometimes it's also because when people are richer, they get more opportunities thrown their way, so they get the chance to become more rich. So in income distribution, if you when you graph it out tends to you want to have exactly the same kind of graph as you might when you graph out the number of connections for particular airports in a system. It's because the network dynamics are roughly the same. It's fascinating that the same thing happens with leaf structure that you tend to have like, there's value if you're like the vein of a leaf to go and basically sort of like merge into one which already has a wider structure. So it's kind of like this arterial structure tends to go in like when you graph out the number of connections that each vein has, it tends to have that same kind of structure as well. So this is called sometimes the Pareto or power law distribution. You have on the left hand side here, you have this is a histogram, you basically have the things on the left hand side are basically the number of the number of things that have low connection and then basically the number of things that have high connection on the right hand side. And the shape of this graph is ubiquitous across many different systems. So like I said, you'll see it with income distribution, you'll see it well, with publishness of airports, you'll see that the natural structure of computer networks. Another fascinating thing is that you'll basically go and see the same thing when you look at say method size in software systems. And if you doubt me, I'd say actually go and sort of graph it out. If you have a tool that goes and gives you the size of methods, one of the things that you'll discover is that you can use exactly the same graph here. You'll find that you have hundreds and thousands of very small methods like one or two lines. Then you have a small number of very large methods. And those are the ones that you would see on the right hand tail of this distribution. The dynamics behind this are essentially when it's when you can preferentially attach to something of higher value, then you basically start having this dynamic growing within the system. A great book that goes into Lusace, this is Network Science by Albert Barabasi. He's like the preeminent researcher in the world right now of power law networks, scale-free networks. And it's a bit math heavy, but it also has great, great examples showing how particular networks evolve over time. And the entire book is available online as well. So it's really worth looking into that if you want to understand more about these network dynamics. The thing I mentioned earlier about method size, there's research around this that essentially many things other than just method size going forward, power law distribution, the size of classes and the size of subsystems all tend to go and have this same structure. And so it's really kind of fascinating to go and see this sort of thing happen. Right now I'm actually like working on a book, which is kind of fun, right? One of the things that's interesting as well is to kind of notice that as I make changes to the various chapters, the number of changes I've made to each chapter follows a power law distribution. There's one chapter where I've made many, many changes. And there's like a trailing list of basically ones that haven't made quite as many changes to. And this is, you know, I have a graph that goes and shows me how this is going. And I can't, for myself, really see why it is this one particular chapter is getting most of the changes. But it just seems to be like, I guess a side effect of how my attention is focused on things. So it's worth going and looking into this distribution and seeing what's interesting about it in relation to your work. As I mentioned earlier, 80-20 rule. You know, a fascinating thing about this, which is like a nice coral area as well, is if you look at commits within a system, you'll basically discover that 80% of the work happens in 20% of the system. That you have some files in your submit system that get most of the commits and most of the change. And once you kind of know this in the context of your work, you can recognize that basically not all the goodness that you spread across the code base in terms of refactoring is of equal value. If you concentrate refactoring on the areas where you're receiving the most change, then you're going to go and get most of the benefit you would get from refactoring. And so it's kind of useful to go and know as you go forward with things. I read this fascinating paper a while back, which is another example of the application of this kind of network science to organizations. It had a very provocative title, How to Prevent Coding Heroes from Destroying the Team. Actually, no, this is the title of the referred to paper, Why Software Projects Need Heroes Lessons Learned from Over 1,000 Projects. There were some people who basically did analysis of a bunch of different GitHub projects, over 1,000 projects. And what they basically discovered was that the contribution across the teams that were working on these projects was not uniform. It wasn't equal. It wasn't like if you had any people, it's kind of like the amount of work done by any one person was one divided by n. Rather, there were a couple of people on each team that tended to basically do the most commits and participate in most of the conversations around pull requests. And this was just like a natural tendency that kind of occurred in open source software development. This was actually posted on Hacker News website around the time that it came out. And there was a lot of controversy because some people were just saying, well, surely this is just something that's true about open source projects. But it's not. If you actually look across in-house projects and there's tooling that can do this, you'll discover that just about every project, there are some people that basically make far more contributions than other people do. Now, it's weird about this because they use the controversial term here hero for basically people that do this kind of thing. And we have this thing in the industry like we don't want people to be heroes. We want to basically spread out the work and basically make sure that everybody is doing an equal amount of work and knows as much about the system as they can so that we have redundancy and everything else and good culture. But this thing just tends to naturally happen. And I guess there's a couple of different ways of looking at this. One is to go and say that the people who are basically going and doing most of this work are the mean people who are trying to basically hog up all the work. But I think what happens more naturally is that as people are working on systems, some people gain a little bit more expertise in certain areas. And then they become the natural person to go to in order to go and get some of those things done. And so they start to take on more responsibility for those things. So it's an interesting thing with this. If we try to go and flatten out the structure entirely, we were really kind of working against our natural tendency on these things. And we have to go and ask ourselves whether it really is worthwhile. As part of the research that they were doing, one of the things that they kind of discovered was that the teams which basically had or actually the contributions made by the people who did the most, who made the most commits actually were of higher quality than people who basically didn't do as many commits. And you might look at this and wonder why. And I think some of that really comes down to familiarity. If you are one of the people who are most familiar with the system, chances are the changes that you make are going to be more in line with the architecture and basically more in line with the correctness of the existing code. So again, this is really kind of a fascinating thing. And it's weird about this because it kind of runs against some of the things that we kind of talked about in Agile. But we'll talk a little bit more about that later. There is an alternative to this, which is really kind of like almost anti-Agile in a way. Which, you know, it's kind of funny going to remember this back after I saw that paper about the distribution of commits on teams. And this paper was written by Harlan Mills. He basically hypothesized back when Fred Brooks was doing his first research in the software development about something he called the chief programmer team. And he basically said that an interesting thing to consider is that since we know that we get increasing benefit from having, you know, having like one mind understanding the whole system, maybe it's good to go and have teams where there's only one programmer. And then there's a person who does testing. And there's a person who's basically in charge of version control and in person who's in charge of documentation. Maybe you only have four or five people, but maybe there's only one programmer along with an assistant programmer in case that one programmer leaves. As far as I know, nobody's actually ever done this sort of thing. But the thing that they kind of recognized even as Roy's 1971 is that smaller teams are better. And having systems where basically the entire system can fit in one person's mind tends to be better. It just doesn't seem practiceable today when we build large systems like we are. So, yeah, there is this thing where basically cognitive limits can constrain structure. As we, as systems grow, we need to go basically sort of like build up different ways of going and structuring ourselves to basically go and deal with the fact that we can't fit the entire system in one mind. And that's a lot of the scaling development we have within software development today. So there is this thing, we can go and break things as well into smaller teams, big projects done by small teams that have to communicate with each other. But as we do that, we end up building a lot more complexity into our systems. And this is true not just in organizations, but also in software itself. You can have a giant method, for instance, and it's kind of like it's terribly complex inside, but there's a different form of complexity that manifests itself. When you take that method and break it into many small methods, and then you have to deal with the relationship between all those small methods. So we make complexity explicit when we basically more, we modularize things a bit more. And sometimes that modularity is a bit harder to change. So I don't know, it's funny, I want to go and take that thing of the chief programmer surgeon team and kind of talk a bit about how we might go and approach that in an agile context. Let's take a look at this for a second. When we talk about cognitive load, the things that we have to deal with mentally, the things that kind of go and sort of make system grow outside of our control are the size of the team, the number of tools we use, the amount of code that we have. Now we can almost imagine that there's like a way of going and making a formula out of this. If we had some scaling factor for the number of team members and the number of tools and the number of code and the number of lines of code, for instance, and just said that if we just sort of set the scaling factors right, we would end up with a number that's less than some number n. And that should be the thing that we really want to go and have in software development. Because it costs us a lot mentally to go and keep track of all these things, we're better when we're working on a smaller amount of code with a smaller number of tools and with a smaller team. And the fact that we can't go beyond n, really, is the reason why we basically have trouble more scaling up software development. One way of going approaching this is to say, well, why don't we just basically have one person teams using only a couple of tools and have them write only a small amount of code? And if we do then we solve all of our problems. But we have the other tension as well that essentially people want more and more features. So systems do tend to grow and they have to grow. So we really can't go and just do this thing of going and having single person teams would be kind of ridiculous. But there are some alternatives. There's this very cool blog called Powers of Two. It was written by a friend of mine, Jake, a long time ago. And he basically made this observation that when you have a particular configuration, some things can kind of just evaporate away in process terms. He worked at a company where basically they had relatively small applications that were supporting experts in a particular field. And they were scoped in such a way that they never really had too much code. They could delete code when it kind of fell out of date. What they were able to do is basically just have two person developer teams. And that's way smaller than a lot of what we consider to basically do with an agile. I mean, you can count peer programming in one way, I guess. But they had teams of just exactly two developers. And so these two developers would pair all day long. They basically would talk to their customer because their customer was in the same room with them all day long. They would be able to talk to their customer. They basically were able to go and sort of trade off the support tasks because a lot of the support tasks were really kind of like across the workday. They didn't really impact nighttime schedules all that much. Version control was very easy. They wrote all their tests. And everything was just very simple. And they were amazed at how little process they had because they were just basically only two people working on the system. And essentially, the system was kind of constrained such that it didn't really have to grow all that much. And to me, that's kind of like the sweet spot for us in a way in software development is can we basically go ahead and sort of structure ourselves so we have smaller projects, smaller numbers of people working on those things and kind of avoid some of the accidental complexity of having large software organizations working on things. And it really comes down to fit against the problem, I think. Some problems are really amenable to this and others really aren't. And then when they aren't, we really are back into that space of going in like trying to figure out how do we grow? How do we basically go into the best deal of communication structure across an organization? And I think it's really fascinating that the issues of communication structure we have across the organization mirror themselves within the structure of the software as well. Microservices were not just a technical thing when they first came into the industry. It was also a way of going and basically getting very small teams able to work independently. And so, yeah, we really are continuing down this path of going and sort of like figuring out how best to go and sort of like manage the tension between the desire to grow and grow teams and grow software and also the limits that we counter along the way as we're going and doing those things. And that thing of the power law distribution, that's definitely an issue that we have to go and deal with. When we have groups of people and when we have groups of software structures, such that there's like a magnetic attraction to go and grow more and more to them, then you basically increase the communication structure. And things start to kind of fall apart. So, yeah, the tension is between n squared and n for us in software development. That's our primary design challenge. Now, if you're trying to scale building, you've got to deal with volume versus surface area. When you're trying to grow an organization, we're trying to grow and grow software. It's all between massive communication structure and stuff which is a bit more like a tree, as opposed to a fully connected graph. And we just have to go and basically balance those things. And I hope that in the context of this talk, I'm going to give you some things to think about and also some things to kind of like dig into as you're trying to go and understand more about how these things impact design. Because I think this frame by itself is very valuable for design thinking and something you can probably carry forward through the rest of your career. So, thank you all very much. And I guess I'll just kind of like open this up for questions at this point. All right. Fantastic, Michael. Like always, you really make us think deeply. So, thank you very much for that. Love the whole power law. I think Adam earlier today was also showing in his court scene tools, he's been trying to analyze and he found the same. So, kind of quite a bit of correlation. And also this whole thing about trying to scale organization, trying to scale agile, what it can do to without changing the structure, I think is again a very important point that you made. So, yeah, thanks again. I will quickly look at the questions that we have here. So, we have a few questions. Wow, we have quite a few questions. All right. So, I'll just quickly read out those questions. So, the first one I'm looking at here is from Vinaya. She's asking following the hero discussion, what are your thoughts on the idea of lone genius? Is it a myth or reality? Is it a myth or reality? Well, I think there's like an issue in the industry where basically what we want to do is we want to go and sort of like say that there are no heroes or no lone geniuses because we know that there's issues in culture when that kind of thing happens. That sometimes people think that they're too good for the team around them or something, which is really a horrible situation where they get special privileges or people put up with bad behavior from people like this. I think that's a significant problem, but I think that the thing that we have to kind of recognize is that that problem is really independent of whether there are some people that just are able to do some things that other people can't, right? Across my industry I've witnessed a wide variation in the amount of ability and software development and some people can just knock out some problems very quickly but they do need to collaborate with others well socially in order to go and be able to solve their problems, solve problems in general. So I think we need to deal with cultural problems, but we also have to recognize that sometimes there are some people that are great performers that basically can be thrown at some hard problems and do very well by them. I don't think these two things are incompatible. Okay, cool. Quickly reading the next question from Praveen. His question is how do we measure positiveness in a team of developers, QAs, DevOps, Ops, PO, etc. Because for every member has different responsibility and separate, they all have separate or different goals. So would this lead to some kind of chaos? How do you manage that I guess is this question because each person may have a different responsibility and a goal. Yeah, well it's funny. I guess the question comes down to why do you want to measure those things? I think one of the things that's really kind of very helpful for us is when we're kind of like evaluating teams is how does the team work together to go and solve common goals regardless of what the individual people are doing? And then there's the thing of like how how do we feel about like how are individual people going and doing, you know, contributing? And I don't think this is really something which is really kind of tied to role. It's really just more like what does the team and what is that person able to, what's the team need and was that person able to provide? Are they getting along with their co-workers? Are they basically contributing? Well, I think there's a lot around this. I think in the end it really just becomes subjective. It's really a matter of like maintaining good relationships with your co-workers and contributing to a goal which is bigger than yourself. Okay, cool. Thanks. The next question is from Carol. If we have one individual working on the program or a system, heroes it causes others not to be accountable or take ownership and would that lead to building compliance in others? So what are your thoughts around that? I think the main thought I have is smaller teams, you know, frankly. I think that there's this natural tendency for this kind of dynamic to emerge and it really comes down to people basically becoming, how can I say, you want to take advantage of the fact that some people are going to basically sort of really dig into particular areas of the system and do well with that. But you also want to basically make sure that you don't have a situation where if they leave you don't really have the capability to go and basically sort of like do that kind of work. So there's a balance between these things. But I think we can't kind of deny that essentially it's not going to be completely uniformed contribution across the team. So I think it's definitely one of those like middle path things where you have to kind of like find the right way to go and sort of like balance the fact that some people are going to kind of like dig into particular areas and others not so much and you know a way of going and sort of like making these effects kind of disappear a bit is to just keep your team size as small as you can. Absolutely. Okay, great. There's the next question from Siddharth. Would it help to scale down your code by using the language like APL or J where all your business logic could fit in on a single page? Yeah, that's an interesting question. It's kind of funny when I'm imagining whoever proposes that kind of smiling as they do this because when you look at the logic it almost seems like that's the thing to kind of do. But language choice is a much bigger issue than just you know raw efficiency. It really comes down to can you hire people that basically will understand code that was written a couple weeks ago or written in a language that they're unfamiliar with. I do think that there's a long arc within the industry towards more terse code in a way. You see it now with a lot of the same things that we're doing with functional programming where basically we're kind of like taking a lot of boilerplate code is kind of disappearing because people are able to use like maps and folds and and various different functional things to go and sort of like articulate algorithms and much smaller amounts of code. So we're going to keep on moving in that direction. But the thing is that really comes down to what things are like for an organization in the context of hiring pool and other organizations. Can they basically create systems that will be maintained in the future? So yeah, I don't see us moving to APL anytime soon. But I expect APL and J like features to start to kind of propagate across programming languages much like functional has propagated across the object-oriented languages. Awesome. I would love to see that. All right. I think there's a last question that is from Rob and he's asking how should we change teaching in software to prepare learners for this future of software engineer where we start designing our software systems and organizations together? I don't know. I haven't really thought about the teaching aspect of it. I think that just getting enough practitioners right now to go and understand these things is probably a good path and kind of hoping that this stuff kind of backtracks into education. But I really think the graph theory network theory are really that kind of the key things here are people to see things in terms of those frames. But maybe I want to have that discussion offline. I think be a great one. I think that this frame is so valuable for understanding design and networks and social systems that it probably should be taught in an integrated way. We see the word socio-technical used quite often these days. And I highly recommend the book team topologies because it kind of touches on these particular things. I think it's really like the first book to try to deal with this in an integrated way. And I'm sure we'll see more and more of that over time. All right, Michael. That was fantastic. Thank you so much. I think we have killed all the questions. So thanks again, Michael. It's a real honor to have you back. Thank you. It's been hard to be here. Thanks.