Milan Milanovic, Microsoft MVP for Developer Technologies and author of the book, Laws of Software Engineering, joins host Giovanni Asproni for a conversation based on the content of his book—a collection of 53 empirical and mathematical laws governing modern software engineering. The book includes some well-known laws, such as Conway’s and Brooks’s laws, as well as other lesser-known but just as important, including Gilb’s and Tesler’s laws. The episode starts with an introduction to the laws and the criteria that Milan used to choose them. The episode continues with some practical hints on how to apply the laws and concludes with thoughts on the importance of the laws for teams using artificial intelligence tools in their day-to-day work.
Brought to you by IEEE Computer Society and IEEE Software magazine.
Show Notes
Related Episodes
Related Articles and Resources
- Site: Laws of Software Engineering
- Book: Laws of Software Engineering
- Software Engineering Body of Knowledge (SWEBOK)
- Book: 201 Principles of Software Development
Transcript
Transcript brought to you by IEEE Software magazine.
This transcript was automatically generated. To suggest improvements in the text, please contact [email protected] and include the episode number.
Giovanni Asproni 00:00:18 Welcome to Software Engineering Radio. I’m your host, Giovanni Asproni, and today I will discuss the laws of software engineering with Milan Milanovic. Milan is a software engineer, startup CTO, author, and Microsoft MVP for Developer Technologies. He holds a PhD in Computer Science and has authored several scientific publications. His work spans software architecture, cloud systems, engineering leadership, team design and practical decision making in software delivery. Milan writes and teaches through the tech world with Milan and he’s the author of The Laws of Software Engineering, which is the book that inspired this interview. Milan, welcome to Software Engineering Radio. Is there anything I missed that you’d like to add?
Milan Milanovic 00:01:00 Thank you Giovanni for the invitation. No, I think you covered everything.
Giovanni Asproni 00:01:04 Let’s start with an overview of the laws. So, can you give us an overview of these laws and tell us where they come from?
Milan Milanovic 00:01:10 That’s a good question. Where they came from actually, but they came from my experience that this is like the first part of the story as probably other engineers and developers who had worked on different projects. After some time and experience, you figure out some patterns, what’s happening in your teams, with your architecture, et cetera. But then for a lot of these things, you don’t know just that they actually have names that maybe some people before you ask also recognize them. Of course, in discussion with maybe your senior colleagues, you’ll figure out like they already know some of these but maybe not all or maybe they know the thing, but they don’t know that this thing has the name. So, I basically collected these things in some kind of a notebook and after some time, I figured out that some people already gave names to these laws and this was really a revelation for me to figure this out.
Giovanni Asproni 00:02:09 Okay. And then also you classify them in seven categories. So, I read this system and architecture, people, teams and organizations, time estimation and planning, quality maintenance and evolution, scale, performance and growth, coding and design principles, decision making and cognitive biases. Yeah, and that’s also how did you choose the categories to classify these laws?
Milan Milanovic 00:02:33 This is also a good question. I thought a lot about this before I started to write because all of these laws were like scattered all over the place in my notebook but also on the internet and I thought about how to properly categorize them. Then I created this order like architecture, people time, quality, scale code and decision making. Why? Because I think that problems compound in that sequence. So, architecture decision constrain people decisions, then later those people’s decisions affect timelines which then drive quality trade-offs and quality problems surface at scale get patched in code and every step evolves human judgment, which is like where these biases live from the last chapter. So, I think the book follows that casual chain instead of just putting them at random.
Giovanni Asproni 00:03:23 Yeah, I have a question actually around that because they said they follow these categories in order but also in organizations sometimes especially big ones, they already have some people in teams organizing some manners and now they have to create a new system. So sometimes they go with that comes before the system architecture as well. Have you ever seen this? What I’m saying here is maybe in some context that is not necessarily the order. I mean you the made this is logical and I’ve seen this happening, but in some context maybe could be different.
Milan Milanovic 00:03:53 Exactly. This is something we’ll talk maybe in more detail later, but I have a framework actually how to use these laws because there are a lot of flaws in different categories that can be also contradicting each other in some type. But that all depends on the context. So, when you have a problem you need to figure out first what are the forces, what laws actually apply there, write them down. Usually, they are like three to five laws and then you need to rank constraints like which force dominates right now like two week deadline makes some laws more important than like maybe speed or performances or something else, you know, in that point of time. So, you just go through this kind of a framework, and I think you can select the proper one in each context.
Giovanni Asproni 00:04:42 Okay. I think we’ll go in more detail about that later. And now another question is actually what makes a law a law? I mean, can you give us an example? Yeah, and also maybe an example of something that to some people might be a law but is not a law according to your criteria.
Milan Milanovic 00:04:59 I think they are actually not a law in some like scientifics or legal sense. I am coming from academy also and I would not consider them laws, but they’re already called laws. It’s like Conway’s law, Brooks law. So, someone already called them laws. So, I just tried to use the same wording but behind some of them there is real research like cap theory or ring man effect. So, there are like sensory show studies about them, but others like more like wisdom in the last 50 years of software development and what happened in our industry. So, I consider them more like guidelines or patterns working in some context where they dominate and where they work and where they don’t work and also how they contradict each other. So, I would say there are laws but in some kind of not so strong sense.
Giovanni Asproni 00:05:46 Yeah. Also you selected I think 63. Yeah, is the one.
Milan Milanovic 00:05:50 It’s like 56 main laws but there are also some kind of, I would say sub effects that I added through these laws.
Giovanni Asproni 00:05:58 Okay. But are there any things, any of these maybe wisdom, parts of wisdom if you like, that you didn’t select because didn’t meet a specific criterion? So, something that say, okay, many people say that but is actually not classifiable or doesn’t make the card form according to my criteria to be a law. Did you find any of that?
Milan Milanovic 00:06:19 Yes, there are some also laws, I mean laws or rules maybe that are existing, but I didn’t find them interesting. Why? Because they’re like I tried to have some kind of process how to make something a law like do they have the right to be in the book and this means that like you have to fill it like I need to know what is that and that I saw this somewhere out there in projects or maybe I read about them and then it needed to survive the time. So, they are sometimes popping up from time to time, but they disappear, they’re like hype.
Giovanni Asproni 00:06:55 Have you got any example of these kinds of things?
Milan Milanovic 00:06:58 There are many, many examples. I remember when I searched about this, there are like some things that people call laws, but I would not say that they are laws or like I tried to have these laws really fully described like with overview origins, who wrote about this. They’re like some things like described just in two sentences or one sentence and that’s it. Just some small things that you cannot consider like a serious law and I just ditched them. I didn’t want it to bring this to my book.
Giovanni Asproni 00:07:31 Yeah, yeah. And what I was asking for, have you got one example of those just to give people an idea of what it could be.
Milan Milanovic 00:07:36 Yeah, I try to remember now which one, like there are a lot of flows talking about like backups. Backups aren’t real until you restore from them or like always have a rollback plan or like external dependencies will always fail or something like that. Probably remember that famous one like there is nothing more lasting than a temporary fix or there are some one-liners that someone could say they are laws but in my opinion they’re not real laws.
Giovanni Asproni 00:08:03 Give maybe one example of one of the laws that are laws just to give people an idea then we’ll discuss a few later.
Milan Milanovic 00:08:10 Yeah. What is law in my opinion of course let’s say Conway’s Law. I think it’s a great example that everyone needs to know about that organization design systems that mirror their own communication structure. This is something which probably all architects know and maybe managers, but there are also some not so famous laws that people should know about. I would say, and this was maybe even more the reason to write this book because people know more about this few famous ones, you can read all other place about them but about these less famous ones you cannot. For example, everyone knows what is the Brooks Law because of the book Mythical Man-Month who probably everyone read, but Gilb’s Law which says that complex system that works is found to have a vault from a system that work. So, it basically says that you cannot build a complex system from the start. You need to first build a simple system, then its theory to improve it and make it complex. These things are maybe common sense to some people, but I find figured out and put in the book a good example where this law is actually abate a lot of times.
Giovanni Asproni 00:09:22 Okay. And also, when thinking about these laws, they come from many different disciplines. Yeah. So, for example, there is sociology. If we look at the law of unintended consequences. Doesn’t need to have much of an explanation this one or the cap theorem about distributed systems. It says consistency, availability and partition choose two or psychology Ringle manufacturer, I think you mentioned that before. So, what is the common thread that joins them in the context of software engineering?
Milan Milanovic 00:09:48 Yeah, that’s a good question because when I gave my book to some people, they said to me like, but this is not related to software. This is like appliable everywhere and this is true, actually a lot of these laws are actually about the team’s human nature and stuff, and they are applicable in any field. You can attach them to any field, but I taught that I should bring them here and explain them in context of software engineering because they really explain what happens in our systems during developing the software systems but they also can explain the same or similar things in different fields or other industries.
Giovanni Asproni 00:10:27 You are saying that basically these laws explain things in many fields, but what I’m interested is also they come from different fields. So, it looks like with software engineering looking at all this maybe something that most of us know but maybe not everybody, is that it’s not only about the technical side of things.
Milan Milanovic 00:10:45 Exactly. This is exact like this sequencing that I created when I tried to categorize them. So, we have architecture, people, time, quality, but also there is a section on coding and scaling systems. So, I think all of these things are important because software systems are socio-technical systems, so all of these effects are inside teams that build software. So, I thought that maybe because some people consider this laws a bit of shorter of this laws usually like 20, 25 laws. But I think that was my first idea maybe to put only these 20-30 main laws — I call them like main laws — but I think that we would lose with that because I know that also all of these other laws I saw while doing or working on my projects that we would lose a full picture of what’s happening there.
Giovanni Asproni 00:11:38 Okay. Also, I picked a couple of laws that in my experience are important for our day-to-day work but not as well-known as some of the others. As I said before, everybody seems to know Conway’s law about the architecture of the systems mirroring the communication structures of a company, or Brooks’ Law, adding more people to a late project makes it later. These are things that very often are mentioned in projects. But I actually today I want to hear your take on some a bit lesser-nown ones, which I think are actually still very interesting. The first one is Zawinski’s Law that says every program attempts to expand until it can read email. Those programs that cannot grow are replaced by ones that can. Now to me — and then I want to know what you think — to me, this looks very applicable to product management. So, I’ve worked in many systems where there was this feature and add that feature basically trying to compete on the number of features. Yeah? And often creating bloated systems. But what do you think, what is your take on this one?
Milan Milanovic 00:12:39 I mean, Zawinski’s Law is actually talking directly about feature creep, and it’s unavoidable in today’s way how product management works. We just try to put more and more features, and all apps actually try to do email at the end. So, I think we all saw it. As you said, I saw it many times in my own projects, and what I maybe didn’t know earlier, I mean I didn’t know there is a law about this of course, but then I somehow felt this like number of features in the app didn’t make our users happy or brought more users to our app. But somehow we constantly produced more and more and more features and put them in the apps.
Giovanni Asproni 00:13:20 Any guesses why that was the case in your project? So, you mentioned an app where you kept adding features that didn’t seem to make the customers happier but still kept adding them.
Milan Milanovic 00:13:28 Yeah, I would say it’s a multi-layered thing. On one level, on the organization level you always want to have more than the competitors, so you are always trying to push more and more to have more features than competitors. Then on the, maybe on some lower level’s product managers need to prove their work and how they prove their work. They produce more features. Also, for developers, this is maybe something that I brought a few times that software engineers should tend more to go to be product mind and engineers. So, when they receive something and when they develop something, they should have this product sense in their mind and think do we really need this? And what is the best way to do this? Maybe we can even not do this at all. Maybe we can do this with some small amount of effort or to critically think about things we do and the futures we make not just to be like future factories. I also wrote in one text about that, yeah.
Giovanni Asproni 00:14:26 I agree. I worked in several systems where there was this drive to put features, features, features. But then that is not always the best decision because also users may end up not really using them or feeling overwhelmed by system that does too much. I’ve got another one that I often use, and this is the Gilb’s Law that says that anything you need to quantify can be measured in some way that is superior to not measuring it at all. Now I have to tell you that I’ve seen Tom Gilb at the conference was several years ago where in a short talk he actually proved that he could measure love just to make a point. So, what do you think about this one?
Milan Milanovic 00:15:03 I think this is one of the, as you said, laws that are not known but they have hard impact on our industry. I think mostly in two senses. The first one is of course everyone’s favorite topic, develop productivity, how we measure them because it’s really, really hard to measure developer productivity and I as some kind of manager and lead CTO had this problem. We are always trying to measure developers’ productivity, and it was over the question, should we do it at all? Maybe it’s better not to do it and if we do it what is the proper way? And I think Gilb’s Law is here very much applicable. Of course there is also another famous example. I would say it’s a tracking technical debt, which is the thing that everyone defines differently. I would say in our industry there is no single definition of this thing, and I saw so many projects that no one is striking that. So, there is even like not managing this term after I needed to change it, a lot of projects to figure it out that there is something called technical debt and then later to figure it out what is it, how to measure it and how to reduce it. So, Gilb is also applicable here because you need to track it because if you don’t track it you cannot improve it, of course.
Giovanni Asproni 00:16:16 So you said for example technical debt, just to give our listeners an example. So, what could be a measure of technical debt? Of course, let’s make it clear that is also contextual. Yeah. So, it’s not that you’re giving absolute answers here, so may depend on the context of the project.
Milan Milanovic 00:16:33 Yes, exactly. I wrote whole text about managing technical debt and I would say there are different categories of technical debt. This is the first thing, like there is let’s say the most simple one like missing documentation. You don’t have documentation for stuff and then people are leaving your project and then new people who are coming to a project have a problem. Then of course, code quality, that’s another good example of technical debt or code degradation.
Giovanni Asproni 00:17:00 Okay let’s s pick one of these. So, let’s say bad code quality, which is an interesting one because sometimes with developers bad quality is code written by other people and sometimes, we have this strange attitude, but how would you measure code quality for example? Just some ideas, I’m not trying to have the final answer because I don’t think there is one, but just to give an idea of how you can measure something like this that sometimes can be subject to opinions, but how do we measure that in a way that could be useful?
Milan Milanovic 00:17:27 Yes, that’s a good question. I had one article last year with Adam from CodeScene.
Giovanni Asproni 00:17:34 Adam Thornhill.
Milan Milanovic 00:17:35 Adam Thornhill, yes. We talked about this. I think his approach is very good. So actually, the way how they measure it, like the first thing is regarding the code itself, does code have a good code design? Does it pass the test have a real intention? There is no duplication. Does it use like fuel cell, which actually is coming from extreme programming that based on all of these like some common issues that can happen, they try to measure it by using something called behavioral code analysis where they actually measure frequency of each file that is it touched. And the code which is more touched is like more interesting for us in the project.
Giovanni Asproni 00:18:15 Yeah. So basically, with some measures that could be, as you mentioned, is tested, there are tests and passes the tests and then what you say there is the amount of duplication that we can check. So, there are some things that we can do that we can use as measures to give quantifiable meaning to technical debt basically. Which is the interesting thing with Gilb’s Law, because this happens with pretty much everything sometimes happens to me in projects that people say we cannot measure that. And then my challenge is then how are you planning to achieve your goals?
Milan Milanovic 00:18:46 Exactly.
Giovanni Asproni 00:18:47 Okay. And then there is another law actually that I wanted to check out because it’s another interesting one that I don’t think is very well known at all. About Tesler’s Law about the conservation of complexity. And I find this very interesting because, well first of all, the law says every application has an inherent amount of irreducible complexity. You can’t eliminate it; you can only shift who handles it. Now why do I find it interesting? I find it interesting because these are implications in how we design our systems and sometimes and now they want to hear your take on this. I work in situations where people try to over-engineer the system to solve all the problems they see, instead of thinking hold on, what can we do here? Where are the trade-offs? So, what do you think about this? And also if you’ve got any examples from your own projects.
Milan Milanovic 00:19:35 Yes, I think this is also one of the interesting laws. I think the main core message of this law like there is no design without complexity. So, complexity is there. So, we rarely can eliminate all of the complexity. So, some complexity needs to stay, but the thing is where is that complexity? And in terms of Tesler’s Law, it mostly talks like, can we shift it and where we should shift it? I would say also this is a more product sense law because you can push all of the complexity to users so they have a really complex UI, they can select this debt, they have a lot of options and they’re overwhelmed. And this kind of software is I would say not user friendly. On the other side I would say Apple is a good example of that. You try to hide from user whatever you can hide.
Milan Milanovic 00:20:27 So you show them only the thing they need to see, everything else is hidden. You try to create maybe better algorithms, anything that can shift that complexity behind and they see just one button they click, and everything is done. So just trying to make something simpler. When you say about the example, I saw examples, I saw examples for example, we’ve built one of our systems, we of course researched the competition and figured out that one of our competitors have really two cramped UIs that have many, many buttons, many input fields, anything that probably users asked or whatever. And we decided to go in another direction like trying really to be simple and to hide complexity behind our below user visibility. So, we will carry this out inside our system. So, user will do the least amount of things he need to do. Of course, this is a tricky thing. You need to know exactly where to cut the rope here because you can go too far and then users maybe cannot do everything they need to do in your system.
Giovanni Asproni 00:21:39 That’s interesting. I think applies not only to end users but also to developers. Especially when we, well developers can be users of APIs. So, if we create an API, and this is particular true with the APIs, when they are, we say they’re powerful, you can do a lot of stuff but then can become complicated and then you want to package things in a simpler manner. But I also think that an interesting thing about this law if you think about it is about tradeoffs is how much do you want to expose so people can do more and how much you want to hide. So, it’ll be simpler to use. I think the tricky bit is how to find the tradeoff there.
Milan Milanovic 00:22:15 Exactly. This is definitely some kind of a tradeoff and as you said, it can be in anything, not only product in general in any kind of decision is how much you push and how much you keep on the other side. Yeah.
Giovanni Asproni 00:22:29 Okay. So, these were just some examples of lesser-known laws as still quite important. But now there is another aspect, how do we use the laws in practice? So, first of all, who should know the laws and their applicability? I mean should be developers, architects, product managers, engineering managers, all of them?
Milan Milanovic 00:22:47 I would say all, there is a reasoning for that. For example, individual contributors get anticipation. Those laws let you see failure before it happens. So, you gain experience by knowing then before something bad happens, then tech leads I would say, or like architects get some kind of vocabulary they can say to more like I think microservices are premature as opinion, you know? Or like about the gas law that says that complex systems that work always came from simple systems is you know, they have a name for that, and they can try to push back on decisions maybe that they don’t sound proper to them. So sometimes you have your inner voice, and this is one part of the thing, but you know now you have something much harder. Like there is a law on that. And then of course managers and CTOs I would say they can use this to diagnose maybe some organizational problems or architectural problems because they now can say or name things and laws which are interconnected with what’s happening in their organizations or projects.
Giovanni Asproni 00:23:52 Yeah, in a sense these laws, when I saw them, they the way also work, they are actually connected seems to be almost a pattern language of sorts. I mean very similar to that, laws that unfold some others but, actually con, well then, we’ll see soon that some will contradict each other as well so that there is some kind of context. Maybe now we will explore this a bit more in how to use them. You know, how should teams use the law? So, we said all the people involved should know them. So, you mentioned also that helps create a vocabulary to discuss issues and maybe sometimes to also to push back. So, what criteria should they follow to decide which laws to look at?
Milan Milanovic 00:24:32 So I would always start with naming the forces. So also, okay, something is happening, we have some kind of a problem or maybe you think there is a problem or could happen. Then you, then you read the book and you of course need to know all of these laws. Then you can say, okay, which laws apply here, write them down usually three to five and then rank the constraints. So which forces actually dominate in this particular context? We are now, as I said, there could be contradicting things, but we should know which is more priority or importance in this.
Giovanni Asproni 00:25:04 When you mention forces, can you give us an example of what you mean?
Milan Milanovic 00:25:08 Yeah, when I say like forces, okay we have a deadline, this is a force. Yeah, okay, next Friday we have a deadline to do something, but on the other hand we need to create proper software and reduce technical and to, you know, do proper things. But then you know you have two things which contradicting each other.
Giovanni Asproni 00:25:29 Let’s see if I’m understanding correctly, I’ll try to rephrase that in my terms. So, forces are things that somehow constrain your ability to do something here. So, you said you have a deadline, but maybe with the team could be also understaffed because there are people on holiday or maybe there is a need of some software, hardware tools that are not there yet. So basically, anything that impacts the ability of the team or teams to actually do something they do in order to deliver. Am I correct?
Milan Milanovic 00:26:03 Yes. If you choose this example, we have a deadline to deliver something on Friday and like this Hofstadter’s Law and we need to do something about that. But then it is a hard deadline, so we don’t have time to do this. So obviously Hofstadter in 1990 Law had more priority in this case for us, you know.
Giovanni Asproni 00:26:21 So which one will, can you remind us of that Hofstadter’s Law? Which one?
Milan Milanovic 00:26:25 Yeah, Hofstadter’s Law say the, whatever you do, it takes longer than you expect. So even when you taking doc accounts for federal law and 1990 rule, say like actually everything you do will take 90% of time, but this last 10% of time actually take the same amount of time because there are some things that you didn’t maybe plan, like integration issues, testing, documentation, all of this can take actually the same amount of time as the mentee, you know?
Giovanni Asproni 00:26:55 Yeah, I saw. We say, okay, we look at the context and the forces and so, based on this we decide which laws to cut and then how do we use them to help in order, you know, to make progress. How can we do that in practical terms?
Milan Milanovic 00:27:08 Yeah, this is exactly one example I gave. So, you need to decide you know, what is most important to you in this point. Okay, there are opposing laws and you need to know how they contradict each other. And then based on your context and your priorities, you need to select the one which is more important in this case. For example, in this case, if deadline’s more important, okay, then we need to go along with this first law that I mentioned. So, I would always say like when you have all of these things which are happening, they have names and then you can know exactly what’s happening and how you can fix the thing or like you can know what to do and what not to do in your particular case.
Giovanni Asproni 00:27:57 So let’s say if I understand this thing. So, let’s say that your example is like a hard deadline and kind of short and you say, okay then well we know according to Hofstadter’s Law that everything we think we should be doing now to get this deadline is going probably to take longer than what we think anyway. And so, based on that, what do we do? It’s like we use the laws as a basics for the conversation to take a decision or take action. Just to give you an example of what I would think of, I would think of like, okay, a short deadline, we know that things will take time. Maybe we should think about scoping one possibility or pushing the deadline to a later point. Or, maybe in some situations adding people might actually help, might or might not depending, because that is also Brook’s Law, you know, that says adding people to a later late project makes it later, but maybe in that specific context is not the case.
Milan Milanovic 00:28:53 Yes. That thing that’s like when already something happened. So, like we are now in the problem. Let’s see, but I think some of these laws like Hofstadter’s Law, they’re talking about something I could not — from my own experience, I feel like developers are very optimistic: we can do everything in a week, you know, we can do it. And all this group of laws is talking about there — we are working in really complex field where there are a lot of unknowns that will be revealed during implementation that extend our timeline. So, we need to include contingency buffers when we are estimating and try not to be overly optimistic when planning. So, you need to know that this thing will happen. That you need to have a bit more care about this because we all saw this on Instagram and in similar Agile methodologies and whoever did estimations that we had a lot of misses. I will probably say in most of my projects we did 90% of misses that we said we will do in some kind of a time or scope.
Giovanni Asproni 00:29:55 That’s an interesting one. I don’t know if there is any law around that. But what I’ve seen in these situations where we miss the estimates is because we first of all don’t necessarily estimate according to any good rule. But also we, many teams I’ve seen, don’t really check the actuals versus the estimates and so they don’t have a way to tune whatever they do. So, is there a law about that?
Milan Milanovic 00:30:22 There is this project managing triangle, you know, which is that every task can have three constraints, cope, time and quality. So, you can only satisfy two of these three.
Giovanni Asproni 00:30:32 That is an interesting one because you know it depends.
Milan Milanovic 00:30:36 Yeah, it depends. Yes.
Giovanni Asproni 00:30:37 But also now you mentioned also laws that contradict each other. Now I have an example here. Which is an interesting one in my view. So, there is the Ringelmann effect that you already mentioned a couple of times I think that says individual productivity decreases as group size increases. So, the more people in a team, the lower the individual productivity will be. But then there is the bus factor that says is the number of team members who if hypothetically hit by a bus would cause the project to be in serious trouble. Basically, the Ringelmann effect pushes you towards smaller teams, you say to be at least the idea is that everybody will be more productive, but the bus factor says, hold on, if you don’t have enough people, you have a problem here because now you are risking to basically stop the project if some people will be unavailable. So how do you actually resolve this apparent contradiction?
Milan Milanovic 00:31:32 Yes, this is something that I think most of us figured out from their careers. I worked in like in very small teams, two to three people, but I worked on projects with 60 people. So very, very big projects. So, and I think everyone who worked on such big projects, they saw that very is small amount of people who really, you know, do the real thing. And then there are some, you know, maybe bigger groups who maybe don’t contribute so much to the problem or to the project like others. And I think this is very much aligned with the price flow. But these two rules, I think, are complementary, not contradictory. Why? Because Ringelmann effect say like smaller teams are more effective. There is even a book I wrote about this tipping point which says like smaller teams are more effective, you have less coordination, less communication, less overhead. So, they are more efficient. But on the other side you cannot depend only on one person knowing one thing. So, you need always to have, you know, at least double someone who also knows about something we are talking about important stuff. Of course, there are some less important things that can be learned fast or either to have proper handover if that thing is possible. But for core things you need to double people who know these things because this is core of your project maybe or your company, but not more than that.
Giovanni Asproni 00:32:59 So the team has to be big enough but not bigger for the definition of enough. That depends on the context. In your experience, what is a good number for a team? Just in your experience? I’m not asking for an absolute truth here.
Milan Milanovic 00:33:12 If you ask me two years ago, that would be different answer than today. Two years ago, I would say five to six people would be some kind of ideal thing for me. But now with the AI technologies and everything which is happening, I think this is like reduced to maybe three to four people at max of course talking about some smaller middle level projects per team.
Giovanni Asproni 00:33:36 Okay. And why did you decide that the number to be smaller than technologies, what makes you?
Milan Milanovic 00:33:42 Yeah, I think now with the productivity that AI technologies gave to us, I think we can achieve more and at least in that sense where we needed more developers before, not so much other roles maybe, maybe some roles called QA also can be differently organized in teams today. But definitely today we can say especially from November last year when we got this much, much more I would say capable models, then smaller teams can do more. And I have example for my company, like two years ago we had nine people working on our project. Now we have five or four to five let’s say. And I would say we are producing more than when the team was bigger. And now with AI that’s even more than before. So, I think we gained a lot of productivity from these technologies but also from reducing the team. And this is exactly what Ringelmann effect.
Giovanni Asproni 00:34:42 Okay. But also, doesn’t that increase the risk as well, because you have a smaller team now, so you are more dependent on the individuals.
Milan Milanovic 00:34:50 Exactly. But as I said, we always double number of people on the important things that that knows these important things. But also, with these technologies, we try to what is always the problem knowledge of course knowledge in in head of people, we try to, we have different tools where we try to grab all of that knowledge from code, from documentation and put on some shared space where AI agents can, you know, read through them and learn fast about our system.
Giovanni Asproni 00:35:20 And also at the beginning you mentioned that you have some kind of framework for the applicability of the laws. Yeah. You say going from basically based on the categories you decided applied in a kind of, in a sequence. So, can you tell us more about that?
Milan Milanovic 00:35:35 Yes. So, for example, let’s say your team is stuck and burning out, you know, and you need to fix something. I would do some kind of a short checklist. So, first is Conway’s Law. So does the team structure match system architecture because this mismatch can drain your team a lot of velocity. Then Brook’s Law of course, you know, did someone add some new people to ramp things up recently that can be a problem? And then of course Ringelmann effect that we mentioned is like your people past eight or nine people, which is somehow considered already a big team. Then Goodhart’s Law, so what kind of metrics we are actually hitting is this, do we measure output or outcome? And then of course in the end technical debt, we also mentioned and broke Windows. Are there small quality issues or problems constantly panning up and slowing us down? So, like for example, these five laws can give you a lot of insights about current issues of your team where, like people are complaining, they’re burning out, they cannot finish, they’re breaking deadlines and stuff.
Giovanni Asproni 00:36:50 Okay. It looks like to me that you’re using those as almost as a checklist of things to look at. Basically to guide your analysis of the situation somehow. Am I correct?
Milan Milanovic 00:37:03 Yes, yes.
Giovanni Asproni 00:37:04 So it’s not necessarily applying them as laws like you know, this is the law you should be doing this. It’s more about us things to consider that might be having an effect in the current context for those particular teams.
Milan Milanovic 00:37:16 Exactly. Yeah, we said, I mean they’re not like some written or physical laws. They are like some patterns that we need to understand in our own context.
Giovanni Asproni 00:37:25 Okay. So, it is a way basically we know that these laws are, you know, some of them are your laws as we know, you know, mathematically speaking, but some of them are empirical things that have been verified in, well verified that have been proven true or reliable many times. And so, use them to assess the situation you are facing. You decide then what to do. Yeah. Is that correct?
Milan Milanovic 00:37:52 Yes, yes, exactly.
Giovanni Asproni 00:37:52 And then based on the assessment, what you do, so you decide based on what parameters are, you apply the laws again to decide what to do next or you have a different system.
Milan Milanovic 00:38:02 I would say, you know, now I assessed like okay, this thing is happening. Based on this, someone who is leading the project or architect or anyone have now new data points, this is now revealed. Like, okay, this is the problem, maybe don’t know what is the problem, this is revealed, the real problem. And now, they have a problem of course in my book and other places they have solutions, for these things, how to solve these things. But I would say here is the emphasis is more on detecting the problem. Because fixing the problem is the second part of the thing. But detecting I would say is a bigger problem because fixing is something we, we already know in the industry how to fix problems and all these things have like some, I also wrote about this in my book, how to solve all these problems in more details. But I find that this like detecting what is the problem and how to name it in the specific context is more problematic. And I feel that this book will help you to be faster in detecting those problems.
Giovanni Asproni 00:39:06 Okay. It’s suitable especially for the detection bit, basically this particular, okay.
Milan Milanovic 00:39:12 Okay. And solving but more to detection I would say. Yeah.
Giovanni Asproni 00:39:15 Okay. And so, what would you suggest to a team that they get to know the laws, these 56 laws, how should they use them and say, okay, we have a problem now we need to figure out what is happening and we have these laws at our disposal. So how are they supposed to look into them, like read them all and trying to match what they’re seeing with what they’re reading or there is some systematic approach?
Milan Milanovic 00:39:42 Yes. Different people have different ways of learning things. My suggestion is to read the whole book, just to have a good overview, what kind of laws we have, how the impact, so just to have some kind of sense about this then use it as a reference book. So, when you have concrete problems, you can get to this aha, this is why I read about the book. Then you open the book, then you go deep dive into more details. I have also the website they can also explore and of course check solutions and some examples I gave for each one. So, it’s a more reference book where I try to put all of these things in one place. But I think it’s good to read it once, from start to end because just to know what is there as we talked at the start, some people know some laws, some know some other laws with this you cover almost everything that’s happening and there is no unknowns for you in the future.
Giovanni Asproni 00:40:40 Will the use of AI change some of those laws? So, I think to an extent, you mentioned something along the lines because as an example of the Brooks Law, you know, adding people to late project makes it later. Now, does it still hold now that teams can use AI coding assistant that can in theory be add virtual contributor to the team?
Milan Milanovic 00:40:59 Yes, exactly. For example, if you have, I think there are even that AI amplifies alone, not ripple them. For example, if you have AI agent, which is orchestrator of other agents and they have some kind of handoff between them, then you, this thing will shape the system. So, they are even more, I would say pronounced today with AI. And I think you said this at the start, they were never about technology. You know, common law is about communication boundaries that shape output, Brooks about coordination, cost, Goodhart’s about what happens when, measurement repair judgment basically. So, it’s more human behavior, mathematical limits and organizational physics. That doesn’t change when new tools come, you know, like AI. So, these same laws hold with others like teams rise Java, Kubernetes or build AI agents.
Giovanni Asproni 00:41:52 Now the application of these laws, obviously the hope for outcome is to produce good software systems. Yeah, satisfy the customers, but also exhibit good internal quality like modularity, test stability, low coupling and all all that stuff. Yeah. Now do you think that improvement of AI tools will change that, for example, make internal quality less relevant? So, I personally had and spoke to people to say, you know what, I don’t have that much about application anymore because the code is generated by AI. I don’t have to maintain it. So, what is your take on that?
Milan Milanovic 00:42:23 I think it’s even more amplified because when developers produce code faster architectural decisions matter more, not less. You know, because generating code at 10 times of speed doesn’t help if commerce law means your team structures fighting your system design. So faster output, amplifies effects of bed structure. And I see this every day at my work.
Giovanni Asproni 00:42:44 Have you got any examples for that? I mean without naming names, if you’ve got some examples, you can give us.
Milan Milanovic 00:42:50 Yes. As I said, when you create some kind of, for example, we got systems in some projects where we have like constantly hitting up, like two teams are fighting with each other and adding AI here will not help us too much because they need to do handoffs. Constantly back and forth, back and forth while someone sit and say like, okay, let’s make this team work together and then we solve the problem of maybe two APIs talking to each other and having problems each day and AI who is like forcing this thing 10 times faster than it was before. So, you know, this thing stays there. Yeah.
Giovanni Asproni 00:43:30 Okay. I also spoke with other people that say, you know what, actually quality will matter more with the use of tools because it is easier to actually drive the agents in the right direction. When you have, when you do that, so for example you say, you know, good modularity, basically you can focus the context on a single module at the time use fewer tokens, but also the need of a smaller context which may make the tool work actually better and examples like this. So, what do you think about that? You are more on this camp than in the camp of quality doesn’t really matter.
Milan Milanovic 00:44:02 Yes, yes, exactly. This is one of a good example because I think venue structure things properly. AI also likes that because AI also likes to work more on smaller things. It’s when you enlarge the context, it just makes more mistakes. But it’s not the deterministic system. So, I think all of these things that we defined before, but also that AI is learned on these things that we built before. And I think it also knows what is good, what is not good, to some extent. Of course, it was trained off a lot of good and paid code, I would say, but they try to make it that it knows the reason what is good, what is bad, and I think if we continue in that direction by ourselves and the working AI, we are on the good track.
Giovanni Asproni 00:44:49 And now I’ve got a final question, which is I think relevant for our current times and is the based on the hype cycle and Amaras Law. You know, we tend to overestimate the effect of a technology in the short run and underestimate the impact in the long run. Now what is your take on this law in the context of artificial intelligence?
Milan Milanovic 00:45:09 Yeah, I talked recently about this in some conference. I think we are still riding this hype because it was obvious that AI is hype. So, you know, if you remember a lot of titles out there, like AI is replacing developers tomorrow and similar stuff. But now we figured out like, okay, there is some restructuring happening, but now you know, all developers have a job currently no one is like laid off without a job. So obviously things will change, but AI is not a solution that will solve everything for us in one click. Like go and finish this because all of us who, who worked with all of these models every day know that they also have flaws, they have problems, they don’t reason properly, they cannot write properly, they created sloppy texts. So, they’re imperfect, I would say the same like whom humans are. They can make us more productive in some parts, but I think the taste and the judgment are still on our side and will be for the future.
Giovanni Asproni 00:46:08 Thank you. So, to me looks like a positive note. The machines will not replace us. No. So we have come to the end of the show, Milan, is there anything we missed that you’d like to add?
Milan Milanovic 00:46:17 Yes, we mentioned this a few times, maybe just to say don’t try to memorize because there are a lot of laws. You know, just remember five to six that match your current problems and know where to look when one you know, hit hard and then just put this book on your table and when you have problem, go and read more about what’s happening. And I think this will work out fine.
Giovanni Asproni 00:46:38 Okay, thank you Milan for coming to the show. It’s been a real pleasure. This is Giovanni Asproni for Software Engineering Radio. Goodbye.
[End of Audio]
