#266 - Software Engineering Laws Every Developer Must Know in the AI Era - Milan Milanovic

[00:02:03] Introduction

Henry Suryawirawan: Hello everyone. Welcome back to another new episode of the Tech Lead Journal podcast. I have a repeat guest today. Very excited to meet Milan Milanovic again. So I checked earlier today, I think we did an episode almost two years ago. So that was about, you know, how to become a great software engineers and all that. Milan actually just recently published another book titled Laws of Software Engineering. I think it’s a very interesting topic, right, talking about laws of software engineering. For some of you, maybe you may have heard a few laws here and there, but Milan actually came up with 56 laws in his books, and even published it on a website. So we’ll talk a lot more about these laws. Are they still applicable in this AI era? And yeah, welcome, Milan, to the show. Looking forward for this exciting topic.

Milan Milanovic: Thank you, Henry, for the invitation. So we meet again to talk about this, I would say, an interesting topic and topic that will be with us for many years to come.

[00:03:02] What Inspired Milan to Write Laws of Software Engineering?

Henry Suryawirawan: Yeah. So Milan, let’s go, the first place, right? How… What made you write this book, right? What’s the background, right? Especially when everyone is talking about AI, you seem to go back to the root of all things, which is talking about law of software engineering.

Milan Milanovic: Yes, exactly. Well, I probably as many others, in our field of software engineering, learned some of these laws in their like careers. When you start as a junior software engineer and then rise up in the ladder, you fail a lot. And some of these fails, failures are, actually described by some of these laws. I was always impressed when I figured out like, well, okay, this thing has a name. So someone like twenty years ago named this problem I have now. And I started collecting them. For some things I didn’t have na- like law names, I have some, like, my explanation of the thing that happened. But during the time I slowly tried to, you know, put this on the paper. Then I saw that also many other people did the same. So they also collected these things. Some things had names, some things didn’t have name, but in the end, when I started to… Like when I decided to start working on this book, because I thought it would be worthwhile, I researched like a lot on this topic and find, figured out that like, there are like a lot of these laws scattered all around, but not on the one place. And so no one could sit on one place and learn everything about them that should be learned, you know.

Henry Suryawirawan: Yeah, so when you talk about failure, right, I also remember, you know, myself learning some of these laws. Definitely no one taught them in the university. Maybe some lecturer would have mentioned it, right? But it’s like nothing in the theory book, right? Whenever we learn from our career or experience, some of these laws is actually kind of like, wow, very insightful, right? Someone already figured it out. And yeah, it’s a, it has a name, so which is something that is also interesting, right?

[00:05:32] How Did a Book on Software Laws Reach Such a Global Audience?

Henry Suryawirawan: So I’ve recently also seen your post that your book has been sold thousand-plus copies, right, for like 74 countries around the world. This is something quite unique in my view, right? So there’s still a lot of people interested in these kind of topics. So tell me more about your wide reach of audience here. What do you feel about that?

Milan Milanovic: Yes. I analyzed like, book, like how it sell in the first two months and it was like 1,500 or more copies in 74 countries. Like that number was not like interesting, but the number of countries was on the one side. But on the other side, maybe it is not because many of these laws are the same in all countries, so it doesn’t change from San Francisco to London or Belgrade or Singapore. So they are, they hold their ground on, in all countries and in places. So from that side, I think it could be expected.

Henry Suryawirawan: Yeah, nice. I think it’s very true, right? These laws wouldn’t change based on your location, your language, software programming language, and things like that. So I think, yeah, congrats for that.

[00:06:49] How Should You Read the Laws of Software Engineering Book?

Henry Suryawirawan: So one thing that I would like to ask before we maybe go into some of these laws, right? How should we actually use your book, right? Is it like a dictionary? Is it something to read cover to cover? Like how do you advise people to read and use your book?

Milan Milanovic: Yes. My recommendation is like, because many of these laws are like on a different level of abstraction. So some are on the like team level, some on architecture level, some on even on code level, on like people level and so on different levels. So you cannot know all of these laws in your head. That like, there are fifty-six laws, but there are more like than sixty or even seventy principles, different like smaller patterns and principles which are part of these laws. So my recommendation is to read the book once, so you have a grasp of like, what can happen, you know, on these different level of abstractions. Then when the, like, when the problem happens tomorrow or some issue you detect, you will remember, “Aha, I saw this. This is that law.” Then you go again to the book or my website and then check the details. There are of course, more details in the book, how to better understand this problem and how to resolve it, you know, in a proper way.

Henry Suryawirawan: Yeah, so I think, for those of us who have been around in our career, I think some of these laws are definitely very interesting, right? But for those of you who are new, maybe in the software industry, or you may never heard about these laws before, right? I think my advice also would be to just at least walk through all the books, right, all the title, maybe the summary. You put actually a good summary, at the beginning of each of the law. So at least you kind of like resonate with some of them.

[00:08:51] Why Does the Book Cover People and Planning, Not Just Technical Laws?

Henry Suryawirawan: So speaking about laws, there are 56 or maybe more, right, like you mentioned, right? But what I’m interested is the like, the span of categories. So it’s not just like when we talk about laws, some- maybe some people think, oh yeah, maybe it’s all about architecture, design, coding principles, and things like that. But actually you have something more, right? You talk about teams. You talk about planning. You talk about scale and making decisions. So tell us why there are so many wide variety of categories talking about laws of software engineering, right?

Milan Milanovic: Yes, exactly. What we think in software usually, especially when we are like starting in this field, that everything is technical, so we are only interested in technical stuff. But what I figured out during my like own career, that software failures are rarely purely technical. So one production incident can lead to organization chart or, like to metric or even to some kind of a bias, that happened. So the book tried to reflect that in a way. Like architecture decisions constrain people decisions, and then these people decisions move timelines that we have on projects, and then these timelines force quality trade-offs. So people try to build complex systems under limited of, like limited time, knowledge, and coordination. So you need actually all these laws about people, math, and organization, not only technical and code stuff, you know.

Henry Suryawirawan: Yeah, so many people have mentioned about it. Software engineering is a socio-technical thing, right? So it’s not just the technical aspects that you need to think about, but it’s also the social aspect like people, you know, project management. I think that’s always… You mentioned something that also quite insightful to me, right? So many of the software failures, software project failures is actually not because of just purely technical, right? So it’s like in the people aspect, right? Maybe in the making the decision, putting something that is probably not like too complex for the stake- state of the project at that point in time, right? So I think some of these definitely very, you know, very exciting to cover some of them.

[00:11:07] What Is Gall’s Law in Software Engineering?

Henry Suryawirawan: So let’s go into some of your favorites, probably. Any one that you would like to pick first as the law to cover?

Milan Milanovic: Yeah, there are laws a few that I like the most because I think they are, they exist almost in all projects or the way how we try to work in this field, at least until we understand them properly. The first one is Gall’s Law that say, like, complex system that works is always found to have grown from a simple one that worked. So I took the example of Instagram in my book, where Instagram was like first some kind of a check-in service, with gamification. But the thing was that this thing didn’t work properly for founders. And then they took one small thing that was like image sharing and built Instagram for that. So, from there. So they started from a small thing and then build up the rest later.

We… In software engineering field, we had similar thing in previous years with this microservices moment. Everyone started to put microservices in all projects, even though probably most of them didn’t need them. So Gall’s Law say like start with the monolith that works, start with simple thing and then split off pieces when you are, you know, you already understand them. The thing i- the same thing is with AI now. So, you can now generate a lot of code, a lot of complex systems, you know. But this is the trap. So generated complexity still rests on assumptions nobody validated. So we saw a lot of generated stuff, but still we didn’t saw some great software in the last few years that happened to us, you know.

Henry Suryawirawan: Yeah, so, it’s very interesting law, right? Gall’s law, right? So, almost every working system, right, a complex system actually start from something that is simple, right? Is this something also quite related to the premature optimization thing? You know, like the root of, you know, of evil is like… premature optimization is the root of complexity. Sorry, it’s not the root of evil. The root of complexity is like premature optimization. Is that also something similar?

Milan Milanovic: Yes, exactly. This is similar, although, Donald talked more about the code, but this is more on the product side, I would say, but it is the same. So don’t overcomplicate from the start. Start simple. They’re more or less talking about the same thing. So if you try to create super complex thing from the start, you will probably fail, you know. Because there are too much unknowns in building super complex stuff from the start. So building the small thing, and this is actually directly bound to MVP approach, which goes well with that. Start with the simple things. Build a small MVP and then build up from there. Don’t build like something really big from the start.

Henry Suryawirawan: Yeah, so I think we all used to hear about all these microservices versus monolith debate right? Although maybe lately it’s less prominent on the internet simply because everyone just talks about AI. But I still remember, you know, we all have this passion about, you know, certain technologies, certain complex systems, right? And we tend to use that.

[00:14:46] How Can You Apply Gall’s Law When Using AI?

Henry Suryawirawan: So speaking about AI, you mentioned there’s the trap of using AI and it ended up with, you know, complex systems, or maybe complex code in the first place. So how would you advise us to actually apply this Gall’s Law when using AI? Is there some tips maybe that you have tried?

Milan Milanovic: Yes. regarding AI, I wrote recently about that. I think, what is more important is not like big production of code. That like, I see everyone is like, “Okay, I’m using 10 agents, 20 agents, 30 agents.” So there are so many agents working all the time, but where is the judgment? And we need to have the right judgment, you know, what we want to build, and also to validate what was built by those agents. Is this like something really valuable for us or not? And like some of these laws are actually, including Gall’s law, talking about that.

Don’t just try to produce something because you can now, you know, easily produce, which is like a nice thing for all of us. But we need to have, like more shift now toward the other side. Like on, from how to why and what, you know. Just to think more on that side, on the thinking side. I see that no one is thinking, everyone is doing. And there is always problem with that. I heard that from one of my CEOs once, who said to me like, why is he don’t do it, doing these operational things? Because when you’re doing operations, you cannot think. You don’t have time to think. And this is somehow, that is like, I also find out, that in this way, no one is thinking, everyone is building. But you cannot build great stuff without thinking. This is just, you know, my two cents on this whole AI movement.

Henry Suryawirawan: Yeah. Especially people who love vibe coding, right? Or using multiple agents, right, like what you mentioned. Or even like one-shot an application, you know, like I don’t know, build a game simulation of blah, blah, blah, and the AI just came up with the program altogether. So I think definitely if you just write it once, you know, and use it once, probably it’s okay, right? But if you try to evolve it and make it a successful product, I think it takes more than just, you know, using AI to do that.

So I think, yeah, it’s very… I would say it’s very timely to mention about this, right? Because we all focus on building, you know, asking AI, prompting AI, thinking about what’s the best context engineering, prompt engineering, loop engineering and all that. But thinking about the what and the why I think is still important.

[00:17:34] What Is Conway’s Law in Software Engineering?

Henry Suryawirawan: So let’s pick the second law. Any law that you want to cover as well?

Milan Milanovic: Yes. I mean, we must, mention Conway’s Law, that say like organization shape systems that copy their communication structure, which means like your organization shape your software architecture. So if you have team, four teams that build a compiler, they will build compiler in four passes. So the organizational chart shows up in their architecture. In modern frame, when we are talking about microservices which we mentioned, so microservice boundaries mirror the team boundaries. And there is this thing called the reverse Conway maneuver, means that you can change the team structure first, and then you get the architecture you want.

And this is not changed in AI, also because it can be human or AI agent. So if you build a multi-agent system, with the separate agents, with like they have some handoff contracts, the system creates around those handoffs and the same like microservices builds around team boundaries. So whoever own the planner agents versus the, you know, executor agents builds boundaries that mirror their own organization. So here Conway runs twice. So human organization shape agent topology, and then agent topology shape system output.

So we should always start with the question, what actually, what kind of architecture we need. And then when we define this, we need to restructure our organization, to be in line with that on our project. Because this design ownership and communication structure first and then our architecture will be enabled by that organizational structure.

[00:19:34] How Should Big Corporations Build New Products Without Structural Reorganization?

Henry Suryawirawan: Yeah, so I think Conway’s Law is, like I think I still remember Vaughn Vernon mentioned it. It’s like a law of gravity, right? You cannot run away from it. So I think, especially…

Milan Milanovic: Exactly, exactly.

Henry Suryawirawan: To me, I think you can only learn it in the hard way, right? In your project, right? But I think one of the most difficult thing about Conway’s Law, although you mentioned about reverse you know, Conway’s Law maneuver, right? So some people just started, you know, with the organization structure like it is, right? So nobody actually attempt to change team structure because, you know, it takes a lot more effort, you know, maybe changing the manager, maybe restructuring the team, and all that, right? It takes a lot more people to be coordinated. So maybe what would you have as an advice, you know, for many, especially the big corporates, right? Where they already have a structure, they already build teams, they have managers, but they wanna build a new product. So what would be your advice here?

Milan Milanovic: Yeah, there is even a wording that HR department actually create architecture because of that. You know, because they’re involved in creation of organization. What is my proposal is always to try to include also architects in organizational definition. So when the manager create, try to create its organization that will build software, also include architects there. Because they can also give useful insights on this topic and help to shape organization towards a wanted architecture we want to have, you know. So this is for sure one good step for everyone.

Henry Suryawirawan: This is my first time hearing, you know, involving architects in, you know, our organization structure. But I think, yeah, thinking about it, maybe it’s not a such a bad idea, right? So having a software architect to actually help structure the team.

[00:21:26] How Does Conway’s Law Apply to Small AI-Powered Product Teams?

Henry Suryawirawan: And speaking about AI, right, many people these days assume, you know, the team size will be getting smaller and smaller simply because now we have AI, right? And that also means like your organization structure will probably shrink, right? And maybe any kind of a team will be just a size of, I don’t know, like three, maybe to seven kind of people, right? This tends to create like a smaller team size, like maybe communicating, coordinating with each other. Do you think there is such an insight as well about Conway’s Law, like for teams that are, you know, like a generalist using AI to build products? Is there something that is worth mentioning here as well?

Milan Milanovic: Yeah, I think it, it’s like Amazon two-pizza team, becomes like Amazon one-pizza team. And I wrote about this in my book in one of the laws. I think the thing will be the same. As I mentioned, with people and also with smaller number of people and with agents, whom these people are using to produce software, it will, Conway’s Law will still hold. So because everything we do and how we do in our organization will directly reflect to our architecture. So people need to have this in their minds when they start to working. So this is for anything more than one person company, you know. It will always help.

Henry Suryawirawan: Yeah, so I also read somewhere when people talking about applying AI, right? So, think of it as if like you have everything from scratch, right? And you design with AI in place, right? Maybe thinking about agents, right? Because if you still rely on your current organization structure, you would end up with the same number of AI agents maybe, right, or AI systems, right? So I think this is where Conway’s Law, again, is very applicable to this.

[00:23:25] What Is Goodhart’s Law in Software Engineering?

Henry Suryawirawan: So the next I would like to pick Goodhart’s Law. I think this is also something that is quite timely and relevant to talk about. So tell us more about Goodhart’s Law.

Milan Milanovic: Yes. Yes, it is. Goodhart’s law is always around. So it say basically that when a measure becomes a target, it stop being a good measure. And we also see this now as we saw this, like fifty years ago. Before, we saw measures like lines of code that were like really a bad proxy in ’80s and ’90s. But it is worse now because you have a model that writes five hundred lines in a second. So the moment you measure AI output, people optimize that metric, not the outcome we want. So it is important, when you create some metrics in your organization, to always pair it with some kind of a counter-metric.

So for example, speed against stability. And then, you know, to always to check, can someone game this, you know, and would this, like this game behavior still produce useful work. So if that gaming produce garbage, the metric is dangerous. The teams, like that win won’t be the ones that generate the most code, I would say. They will be the ones whose structure isn’t fighting their system, a company, or who measure outcome, not output, which actually Goodhart’s law said to us.

And when we talk about AI, we also saw this in this tokenmaxxing, where some companies try to, you know, say, like, like more tokens the better for you. And then, of course, people always try to align their work towards that metric. They try to produce more and more tokens. But the real outcome, the real quality was not there, so they didn’t achieve what the organization wanted. They just optimized on that particular target they had.

Henry Suryawirawan: Yeah. So I mean, yeah, talking about Goodhart’s law, definitely we may have seen it from time to time, you know, in the software development world, maybe thinking about velocity, right? You know, we used to talk about story points, lines of code, always, a classic kind of example. People talk about DORA metrics as well. And these days it’s about tokenmaxxing, right?

Milan Milanovic: Yes.

[00:25:52] What Are the Best Examples of Counterbalance Metrics for Leaders Today?

Henry Suryawirawan: I think when we had the model like cheaper than today, I think tokenmaxxing is like a very, very applicable thing. Many people are like just ask developers to spend as much as possible on tokens, but I think there’s a little bit of pause simply because the AI model cost is rising at the same time, right?

So I think Goodhart’s Law definitely is very important, especially for leaders, right? Because leaders sometimes create this, I would say like, I don’t know, KPIs or part of the performance review, a metrics, right? You mentioned about having a counter-metrics or counterbalance. Any kind of a good examples that maybe leaders can use these days, maybe kind of like a best practice in the industry now? Like is there a such thing?

Milan Milanovic: I think we should always start from what kind of outcomes we want to focus. So the focus should always be outcome, so not output. We are constantly trying to measure outputs, you know. All of these things we’re now talking about are outputs, lines of code, number of tokens. So, and the… what really surprised me with this tokenmaxxing is that like no one remembered this Goodhart’s Law, obviously. Because every time when we had such thing, it bounced back in the history of software. And this is one of the reasons I, why I wrote the book. So we cannot measure things in software like this, so in number of things, you know. Number of things produced will never produce a good value. What will produce good value is like what outcome we want to achieve, and did we meet this outcome or not? Or we can say also, did we meet in timely manner with the right resources and, you know, in the budget and all of the things, but not by measuring number of features, tokens, whatever. So this should always be in mind of especially leaders as you say, because they define and shape this KPI structure and the whole organization.

[00:28:06] What Kind of Outcomes Should You Actually Measure?

Henry Suryawirawan: Yeah, so definitely, right? I think focusing on outcome is definitely is the most important thing, right? But talking about it, right? Because it is such a common thing in the industry, right? Such anti-pattern that people always follow, right? I think one of the difficulty, right, is just like people find it hard to actually measure outcome. Or maybe sometimes it’s also a lagging thing, right? You can only measure it after certain times, right? And that’s why people focus a lot on maybe output or proxy metrics, right? So yeah, this is probably one of the danger, because like it’s easier to just quantify and measure it. So, and especially some tools actually also produce this out of the box, so you can just use that, right? So I think focusing on outcomes, maybe tell us like what kind of outcomes that is, you know, like we should measure. Is it like business outcome? Is it like technical outcome?

Milan Milanovic: It can be either. So I would always ba– like, we should always start from impact. What kind of impact we want to achieve? So okay, we want to be like the best company in the world in this area, or like we want to have like five thousand users per month, you know? Or we want, you know, whatever, what impact we want. Then we translate this to outcomes, what kind of outcome we need to achieve. And for example, OKRs are good to define and measure that outcomes. And of course, then comes outputs, you know, because they are connected to these outcomes. They are fine. They– There could be like just indicators. So, okay, I listen for these indicators, like these outputs. Okay, we spent like this, we created this number of features, etc., etc. But this should not be the key thing, you know? The key thing should be like what impact we achieved and did this impact was actually the thing we wanted to achieve, you know, with what we did in our project.

Henry Suryawirawan: Yeah. So for any of leaders who are listening currently, right? Always remember this Goodhart’s Law. Because once you set a certain kind of like metrics, right, people will just follow. I mean, there’s a– this phrase, right, “People behave as to how they are measured,” right? So definitely especially metrics that can be easily gamified. I think in the industry, classic examples will be like code coverage, right? Where you can exactly create 100% code coverage but without testing anything, right? Same thing with, I don’t know, like with DORA metrics, you know, agile, velocity and things like that, right? So always remember the picking the counter-metrics, right? The kind of things that make sure the, there’s a check and balance between one metric and the other. So I think definitely very classic Goodhart’s Law. I always remember this whenever I become a manager, right, so that I don’t pick the wrong metrics to choose.

[00:31:01] What Is Hofstadter’s Law in Software Engineering?

Henry Suryawirawan: So I think looking at the list, I would like to cover the Hofstadter’s Law next, because I find it quite interesting to discuss with AI. so yeah, maybe tell us about Hofstadter’s law.

Milan Milanovic: Yes, Hofstadter’s Law was like always with us, especially when Scrum started, because it directly impacted the whole thing regarding planning, estimations, story points. Because it says like it always takes longer than you expect, even when you account for the Hofstadter’s Law. And why is this? Because we– the software is a complex thing, you know? It’s, it is in the area of very complex things to build. And we cannot, you know, know everything that will happen. And it also goes in line with this rule called the 90-90 rule. Why? Because, you know, let’s talk about it now. You have AI, it like can generate your 90% maybe of code. That’s the easy part. But then that 10% that you haven’t thought about maybe in details are like integration, edge cases, testing, maybe writing docs and similar stuff, which could actually took the same amount of effort.

So if you planned like three days, it could be easily six days because you thought, okay, the biggest thing is creating this. I will like, I need like two, two and a half days, and then this half day for the rest. But that rest could be the same size and same amount as this first part. And this is exactly this 90-90 rule, which nicely connect to Hofstadter’s Law. So we are not good at estimations and we need to take this into account, especially when estimating the complexity of software. And of course, there are some countermeasures that we can do here, especially this to try to have this in mind when we plan and to have all of these buffers and things that could happen and that maybe happened in the fu- in the, past, that could happen in the future. But we need to have this in mind when we plan things or when we say that something will, you know, last for that number of time and et cetera.

[00:33:35] How Does Hofstadter’s Law Apply in the Age of AI?

Henry Suryawirawan: Yeah. So yeah, that I think this is also again classic, right? So I think it’s quite funny. It always takes longer than you expect, right, than what you estimate. It’s quite typical, right? And you mentioned like people, like when you mentioned software is a complex thing, but many people actually assume software is easy, right? Especially the so called non-technical people, right? And now these days, especially when people think about AI, it’s, they think it’s even easier for, you know, writing or producing software. Some people even think like you can just easily, you know, reduce number of people, but you can still produce a lot of things, right? So tell us, is it still kind of like applicable about this law with AI, right? Because now it seems like once you can churn out so many agents working at the same time, maybe you can have things faster.

Milan Milanovic: You can take f– you can be faster, but I think it’s even worth it in pause because you now cannot know, for example, especially with people. You talk about vibe coders, they cannot anticipate, you know, what will happen after they, you know, vibe code something or when they create something. How much time the other steps will take. Because when you hit the wall where the, like, maybe AI cannot longer help, maybe you can need to contact some people, need to do something manually, then these things will hit hard, you know, hard, hard back.

So always, for this law in particular, I always say, like we should always have these contingency buffers in our schedules. And don’t be overly optimistic in planning. So we need to acknowledge that delays happens and the factors that goes into timelines and our expectations. I find out that, you know, developers are always optimistics. It always be fast. Now with AI even faster. But the things will have their stops in that timeline, and then we need to try to anticipate those things and, you know, plan accordingly.

Henry Suryawirawan: Yeah, developers are always optimistic and also try to delay everything almost to the deadline, right? This is talking about maybe another law, right? When, w- I forgot what’s the law. I think it’s like when you have a deadline, right, everything will just finish closer to the deadline. I think you have it as well in one of,

Milan Milanovic: It’s ninety-ninety rule, yeah.

Henry Suryawirawan: Yeah. So I think definitely this one, you know, when you make estimates, right, always have buffer, right? So things will somehow go wrong, especially I think, very importantly, right, AI currently just focus a lot more on the producing the code part, right? But like you mentioned, right, there are other necessary things that happen when you want to, you know, produce software that works for, you know, external users, right, or working in production. So it could be integration testing, building, deployment, security stuff, and all that, right? Always remember there are so many aspects that you need to think about.

[00:36:41] What Is the Dunning-Kruger Effect?

Henry Suryawirawan: So maybe if we pick the last law, what will be the last law that you think will be great for us to cover?

Milan Milanovic: Well, let’s, talk about Dunning-Kruger effect. It is like from the biases or behavioral section. It’s not like about the project times and estimations. Maybe it would be interesting for people to know about it. It says like basically, that people with low ability have tasks overestimated, while experts underestimate themselves. And when we bound this to the thing we talked about, AI code generation, people now ship like convincing looking code they can’t evaluate because the tool hides the gap in their competence, you know? What we can do for sure is that we produce something. So we produce some code, but we are not sure is that code good and how this thing will, you know, work when it hits real users or real infrastructure and the real world, you know. So we need, always to take this into account and to be especially when we are like, you know, we don’t have a lot of competence about something. Don’t be ignorant about some signals you are getting, you know, because our awareness grow faster than our skill. So learning initially reduce confidence only to rebuild it.

So we need to, when you saw someone who is the expert in some field, you will see that someone is always talking about, you know, trade-offs, probabilities. Like it depends. You heard about this probably. Not confident about everything. So, you know, and I think we have the same thing with AI. I see a lot of people who say, I would say pro– in a proper way, we still don’t know what is the best practice now, how to work with this thing. But on the other side, I see a lot of people who are like, “Okay, like I have, you know, I just started to build this thing and I’m the world expert in that, and I know everything about that”, you know. And this is probably not true, you know, because we are still new in this, and we need some time and experience and, you know, production scars to understand these patterns, what works, what don’t work. And then we can confidently say, like, confidently, what works properly and what don’t, you know.

Henry Suryawirawan: Yeah. When you mentioned about that, I remember a few examples like on social media, right, where people talk about using AI, like especially if the tagline, right, see, it’s simple, right? I can use AI and it just runs by itself, right? Even they are selling course for people to make money just by using AI running autonomously. I think I remember about this example for some reasons. Yeah, this is probably quite applicable, right? So people who probably less expert in a certain area, they think to, like they overestimate what they can do. AI definitely amplifies this a lot, right, because people assume things will be easy. But yeah, speaking about experts sometimes, yeah, they also kind of like underestimate, simply they want to know more details and get more confidence before, you know, deciding on something. So I think definitely this is kind of like a bias, cognitive bias thing as a probably that happens in our mind, right?

[00:40:10] How Does the Dunning-Kruger Effect Apply to Experienced Engineers Learning AI?

Henry Suryawirawan: So speaking about, you know, like maybe the software engineers who have been doing this for a long time, right? And AI is kind of like a new thing. What do you think? What will be your advice for so called these experts, right? Like people who are more competent about software engineering now that facing the challenge of, you know, learning AI. Obviously, people will think, “Okay, I don’t know anything about AI.” Is there any good tips that you wanna give with the angle of this Dunning-Kruger effect?

Milan Milanovic: Yeah, I think I see the other part of this story. It’s imposter syndrome. I would say a lot of people who learned, as I learned and probably a lot of people in some past life, I would say, how to do this, we now feel like imposters. Like, we are like, this is all new. We don’t know how to work, and we maybe feel that we don’t provide value now like we provided before. But I think, if we learn these things properly, like these thing we mentioned, the best practices, how to work with that, and taking into account some things that are here to be for long time, that, like Lindy effect talk about this, that will be for the next 50 years probably with us, like they were like 50 years behind us. Your knowledge and value will be even more important to companies than it was before because that knowledge don’t disappear. You know, it just changed, and I would say even amplified with AI. Because now we have the same thing that we had, but now we can even produce more, you know. We can produce more things in that same domain, but we still keep the roots, like on the same way like we did before.

Henry Suryawirawan: Yeah, so for people who don’t know about Lindy effect, right, the, it says like the longer something has been in use in the maybe software industry, right, the more likely it is continued to be being used, right? So we’re talking about, you know, maybe fundamentals, technologies where that has been around for many, many, many, years, right? I think it will still continue to be applicable, right?

So I think for those who have been around in the industry, don’t get disheartened, you know, whenever all this new AI craze happening, right? So, the one, one for- one thing for sure is like we have to pick it up and learn, but also don’t forget all these fundamentals, including the laws that Milan, you know, wrote in his books, right?

[00:42:46] Are Any of These Laws Becoming Less Relevant Because of AI?

Henry Suryawirawan: So, so far all the five laws that we have covered seems like it is still applicable in the AI world. How about the others? Are there laws that become less relevant? Is there such thing that you have found?

Milan Milanovic: I wouldn’t say. So, when I wrote the book, like I wrote it du-during the AI era, and I tried to reflect in almost all of them how they, you know, tackle it. Of course, there are some laws like that are not directly connected to producing software, like these behavioral things and some others which are, you know, not directly. So they are not directly connected to AI, but I would say AI is present in a lot of them and even amplify some of them with this because I’m afraid that even people who knew some of this will forget them because of AI. Everyone thinks like, “Okay, this agent will create everything for me. I don’t need to care about anything anymore.” I think they’re wrong, and this will bite back later if you skip it.

Henry Suryawirawan: Yeah, so I think, yeah, just what you mentioned, right? I think people seem to be in this AI mode now, right? We seem to forget such things exist, such laws exist, right? And we also probably think this is a new disruptor that is totally new, that will definitely change things for good, right? That’s like different, totally different altogether. But I think just like what we covered, right, all these laws are probably timely, timeless, right? it’s like applicable over a long period of time. And yeah, maybe looking forward to see new laws being created when we talk also about AI, right?

[00:44:32] What Does the Lindy Effect Say About the Fate of Software Developers?

Henry Suryawirawan: So you mentioned about Lindy effect, right? So I think this is quite important for any software engineers because people now these days, some of us are actually quite disheartened when we talk about software engineering. We think the profession will be gone. You know, like we don’t need so many software engineers. So what do you think? Is this gonna be true, or is this gonna be like a fad, right? So, any thoughts about this?

Milan Milanovic: I think software engineers will be even more valuable than before, but people are mostly talking about counts, you know, how mu- how many people we need. And this thing will change. For example, you mentioned maybe on this project, we will not need 10 people, maybe we’ll have, you know, three people. But the things, the other things will be even more valuable because, you know, engineering world is not only, you know, code production. I remember seeing the best software engineers I met writing one line of code per year, you know. So their main, you know, thing they did for our company was not writing code, they are solving problems. So I basically believe that software engineers are problem solvers. Writing code is, of course, our main thing how we solve problems, but not the only thing. If you can solve problems without coding, that’s the best thing.

So, you know, no code, no problem, because any amount of code you have, and now with AI we will have, it’s expensive to maintain, to run it. You know, you need to pay for that in production. So it should be always like, you know, try to be simpler. And I think the things will restructure. Teams will restructure them and the companies will become maybe different, maybe more agile in this regard. And, but the judgment code is still here. As I said, we produce lot of more code, but I didn’t saw the new great software that was created in the last few years. I don’t– cannot remember anything new and big we are now using, you know.

Henry Suryawirawan: Although maybe some of these AI frontier models will say differently, right? Because they will say, okay, we have come up with this new model that can solve, you know, I don’t know, even a certain, kind of like role, right? Maybe accountant, finance, software engineer, right? So I think there’s always this debate in the industry, I always find. But I think you, you mentioned something that is also, I would love to mention it one more time, right? Lesser code is actually much better, right? And these days it’s very easy to produce code. And it’s also very easy to lose track because it takes a lot of effort to actually even to review AI-produced code, right? And maybe we can talk about, you know, building the evals, building all these guardrails and all that, but I still think it’s probably not humanly possible if you continue churning code using AI, especially multiple AI agents at the same time, right, to actually understand what’s going on with the code, right? So I think engineers definitely need to watch out about this.

[00:47:49] What Is the Best Career Advice for Junior Developers Entering the AI Landscape?

Henry Suryawirawan: How about the juniors, right? Juniors who just started. I heard so many times that they found it even difficult to get the job in the first place. Any advice that you know from your parts of the world there?

Milan Milanovic: Yeah, missing. I mean, we, like, complain a lot, but for juniors, it’s even worse because they cannot find jo- new jobs so easily. On the other side, what I heard also from companies, this Dunning-Kruger effect is like hitting hard because they start to vibe code and they think like, “Okay, I knew everything now,” in a very short time, which is not true, and then hit the wall later. So for them it’s even harder than what it was before. But, you know, I think there is no magic recipe. They need to, you know, to learn things properly. They need to learn these fundamentals, which we mentioned with the Lindy effect, like algorithms, system design, databases, because this knowledge will be needed even with AI here. Then of course AI technologies.

And then, what I found, find, much more important than di- just this coding story is like, which is what not often mentioned is like domain knowledge. I think domain knowledge is something much, much more important than just knowing how to code something. Because this is something that is hard to gain, you know, and expensive to lose people. And bus factor is talking about this, you know. Do you have people who have enough knowledge and how much? So we need to think more up in this direction. So these people who want to learn and want to work, and who has like good skills. And when we talk about skills, there are also people skills which are very much important, maybe even more important than technical skills. Then of course technical skills. To focus on this ownership and domain knowledge learning, because this part will be needed for many years to come.

Henry Suryawirawan: Yeah. I always find it quite difficult for them, right, empathize them, this kind of situation, right? Because definitely when you went out of school, right, you don’t have much experience, right? Probably what you learn also quite limited, right? My other advice would be just getting more hands-on, right? Build more things, right? Maybe, you know, learn about some technologies and also learn about fundamentals, right? You mentioned about fundamentals.

[00:50:34] What Are the Top Five Must-Read Books for Software Engineers?

Henry Suryawirawan: And I like, like in your recent post as well, maybe in your newsletter, in your Substack, you cover about this must-read books for any software engineers. Maybe talking about also classic books. Any kind of books that would want to advise us all to read, right? Maybe if you can pick top five, what would be those books?

Milan Milanovic: Yes. Well, I’m the avid reader, you probably know, and I write a lot of about books. Why? Because I think books are important. They’re still important. Maybe people think they are not, but a lot of these books I talk about are actually those books that held the Lindy effect, you know, law there. They are like, they are writing about things which are like, which will held for many years to come. And of course, when we talk about this, like the best books, I always recommend Pragmatic Programmer because this book actually talking about good habits we need to have when working in this area. How to create, how to become real software engineer, and this is something, everyone should read, like as the first book. It is old one, but there is new release, like 20th anniversary edition.

Then I would also recommend Clean Code. Some people don’t agree about this, but I think Clean Code still have a lot of good insights on how code should look like, how good code should look like. And, together with Philosophy of Software Design by Professor Ousterhout, they are good pair on how the good code should look like. And when, you know, when AI produce some code, you can review it, you can check like does this make sense or not? Maybe sometimes it will not make sense.

Then, of course, some of the books regarding algorithms like Grokking Algorithms, which are, you know, basis to learn about how things really works. And of course, one book I wouldn’t like to skip is Designing Data-Intensive Applications. There is now a second edition. I wrote a detailed review like last year about this. And this is, important book for anyone working, with like, in distributed systems who want to know more about advanced data concepts, databases, data models, transactions, replications, consistency. All of these things where AI can help, but you still need to understand what’s happening there. So, and of course, as a bonus, my book, I think it will go well along these ones, yeah.

Henry Suryawirawan: Yeah. I like the bonus part, right? So definitely read books still, right? Some people actually think these days, I mean, we all kind of like getting very little time these days, right? And, we prefer to use, I don’t know, maybe last time it was like audiobook, right? And maybe there are some products that also summarize book. And these days you have AI that can summarize books quite easily as well.

Milan Milanovic: Yes. I mean, you can use that. And I mean, this is the reason why I held my book sh- I would say short, because every law has like two to three pages, four at most. And you also have key takeaways on the start. So it’s easy to grasp, every of these laws, you know. There’s also audiobook.

Henry Suryawirawan: Yeah. So one thing that I also learned about, even when you use AI and book, right, for those people who read a lot, you will benefit a lot when using AI simply because first, obviously you need to craft the prompt. That’s the given thing. But also you need to read what AI is outputting, right? So, and if you’re an avid reader, definitely it gives you a good competitive advantage, you know, when you use AI simply because you love to read and you can, you know, make sense of stuff faster rather than those people who don’t love to read, right?

Milan Milanovic: Yes, exactly. My way of working with AI, I wrote, I think I published this today, is like I mostly focus on the research and planning part, because I do this part, especially when doing some bigger things. I tend to focus more on there, not on the implementation itself, because if we research thing properly and plan thing properly, the implementation will don’t get us surprises, you know? And so try to focus more on this thing, creating plans and reviewing plans, discussing this with AI or, you know, with other people. And then when you have concrete implementation steps, AI is good at that part to just spit out the code.

Henry Suryawirawan: Yeah. I think this is a pro tips for everyone who use AI, right? Always start with plan mode first, right? Always research first rather than jump into the implementation, you know, vibe code stuff or one-shot thing, right? So I think definitely you need to think a lot more. And don’t forget, I think I like what you mentioned earlier, right? Think about the outcome that you wanna achieve, right? Not the exact output that you wanna produce with AI, right? So think about the outcome, what you wanna achieve, what you wanna do, and then use that, with AI, right?

[00:55:46] How Can Software Engineers Apply These Laws in Their Daily Work?

Henry Suryawirawan: So Milan, I think we have covered a lot of things. Is there anything else that you think we should cover before we wrap up to my last question?

Milan Milanovic: Yeah. Maybe just briefly to mention, so how I would use these, like laws in my daily life. So try to name forces, and then think like when you read the book, of course, which laws apply here? Well, there are probably usually three to five laws. Then rank the constraints, which constraint is the right in this point of time. For example, two-week deadline, of course, beats the scaling worries that you have. And then check also the opposite. So for each law, you will, you know, find where it breaks. And this is some kind of, you know, algorithm that works well when working within software. And by applying these laws you will just go, you know, much faster from the, you know, issue that happens to the right answer you need for that situation.

Henry Suryawirawan: Yeah. And I would like also to mention that you also have the website, right? Maybe a companion website for this book, right?

Milan Milanovic: Yes. Yes.

Henry Suryawirawan: Where you can easily filter based on certain category or if you just wanna jump to a certain law straight away. I think that is kind of like also helpful, right?

Milan Milanovic: Yes.

Henry Suryawirawan: So yeah. I cncourage people to check out this book because this is a timely thing, coming back to the Lindy effect, the fundamentals that we talk about software engineering. And I think many of them, if not all, are still applicable even though we are dealing a lot with AI these days.

[00:57:26] 3 Tech Lead Wisdom

Henry Suryawirawan: So Dr. Milan, thank you so much for your time. It’s a great pleasure to have you again. If you still remember last time, I have one tradition that I will ask for my guests. I call this the three technical leadership wisdom. Maybe you can share a version today, new, right? Maybe with some laws, I don’t know. Maybe if you can share, that would be great.

Milan Milanovic: Yes, three leadership wisdoms. I will just try to summarize our talk, you know, a bit because I think we said everything important. So the first thing is name the force before you fix it. So most technical problems are actually organizational. So the team that can name what’s pulling it, solve that faster. So this is the spine of my book.

The second thing is like optimize for judgment, not output, you know. Especially now the cheap part is producing code, but the variable part is knowing what’s good, and this will be amplified in the future.

And the third thing, I think it’s important to mention, is the write thing down. So the knowledge your senior has is your most fragile assets, and bus factor talk about this. So the whole book exists because of writing beat this problem of constantly rediscovering things by new people that are here for, you know, for so long. And it will– there will be for many times to come.

Henry Suryawirawan: Yeah. Wow. I think it’s very good. I find this kind of like, like a law also, right? It is kind of a bit applicable, right? I like that optimize judgment rather than optimize output, right? So I think definitely it’s a good advice for us, especially in this AI era.

Milan, thank you so much for the conversation. Again, if people wanna check out more about, you know, your book, your stuff, maybe if you can advise some place they can reach out to you online.

Milan Milanovic: Yes. They can check the website of the book called the lawsofsoftwareengineering.com. And you can– they can filter and check the all the laws, with filters, grouping, and even by seniority. They can also check the book there and they can contact me on LinkedIn, Twitter, or my personal website and to stay in touch. I would always– I’m always open to hear what people say, to hear for feedback, and anything interesting.

Henry Suryawirawan: Yeah. And not to mention you also have this popular newsletter, right? I think Tech World with, you know, Milan, right? So I think please do check it out, right? It is quite– It has been around for quite some time, right? So I think it’s quite popular for people to also follow. So again…

Milan Milanovic: Yes, tomorrow will be interesting. Tomorrow will be interesting thing in my newsletter with one of Google principal engineers and my recommendation is to read it. It is about the future of software engineering and it tackles a lot of things we talked about today.

Henry Suryawirawan: Nice. Yeah, so again, thank you so much. So thanks for writing these laws. I think, again, it is a timely reminder for all of us in the industry, right? About some things that probably don’t change often, right? And they are kind of like the most, like I would say, one of the most important things that people should know in the software engineering industry. So thanks for writing and summarizing these laws.

Milan Milanovic: Thank you, Henry, for the support and invitation to talk about this today. I hope this talk and my book will be valuable for people in our industry.

– End –