DOP 288: The Laws of Software Evolution
32:12 Share

Until yesterday, we did not need GPUs. Who needed GPUs? Nobody. Now we do. So now we're not talking anymore about CPUs only, but we're talking about CPUs and GPUs. That's making it less stable because we are increasing complexity, right? This is DevOps Paradox, episode number 288, The Laws of Software Evolution.

Welcome to DevOps Paradox. This is a podcast about random stuff in which we, Darren and Victor, pretend we know what we're talking about. Most of the time, we mask our ignorance by putting the word DevOps everywhere we can and mix it with random buzzwords like Kubernetes, serverless, CICD, team productivity, islands of happiness, and other fancy expressions that make us sound like we know what we're doing.

Occasionally, we invite guests who do know something, but we do not do that often since they might make us look incompetent. The truth is out there, and there is no way we are going to find it. Yes, it's Darren reading this text and feeling embarrassed that Victor made me do it. Here are your hosts, Darren Pope and Victor Farsen. Back in September of 1980, Victor, how old were you then?

1980, I was six years old. I was 14. There was a article, not a blog post, an article in a magazine, like a paper magazine called IEEE. Have you heard of IEEE before? No. No? Oh, you should have heard of IEEE. What's the magazine about? IEEE was the International something of electronic electrical engineers, something. I should know that because I was an electrical engineer, but I don't remember now.

At that time, I guess that five people read that magazine at that time. Probably a few more than that. But there was an article from Manny Lehman. He was a senior member of the IEEE. It was called Programs, Life Cycles, and Laws of Software Evolution. Now, I'd never heard of this before. 44 years ago. 44 years ago. As this episode comes out, it's November 6th. So it should have just been over 44 years since this article was published. Let's see if it holds up.

Now, I found a blog post, that's how I found out about the article, from Matt Rickard that was published in Giga Figure September of 2021. So in his case, it was 41 years ago. Now, we're three years on, so it's 44 years. There are five major points within this post. I am going to link to Matt's blog post from September of 2021 down in the episode description. But that one has a link off to the original article. And boy, is it original.

Fonts in the 80s were so bad, especially in print. But we'll leave that there. Five big points. We'll come back and look at them again in a minute. Now I'm going to have to look at my notes. Number one is continuing change. We'll get into each point in a minute. Number two is increasing complexity. Number three is the fundamental law of program evolution. Number four is conservation of organizational stability. And then five is

Did I say the wrong? No. Conservation. Oh, conservation. Number four is conservation of organizational stability and conversation of familiarity. I'm not even saying these words right. Anyway, let's take a look at number one. Continuing change, because that one I can pronounce. A program that is used, and that is an implementation of its specification program.

reflects some other reality, undergoes continual change, or becomes progressively less useful. The change or decay process continues until it is judged more cost-effective to replace the system with a recreated version. So 44 years ago, he was stating that at some point it costs too much to maintain a system and it needs to be replaced. My words, not his. Yes, and that's true.

And now we're going to enter immediately into the monoliths versus microservices type of conversation, right? If the system is inseparable, then you're right. If you cannot take away something and replace it with something else. Do all systems need to be replaced? Yes, or most of the time, yes, because the needs change.

And that's not only software, that's with everything, right? If the car you bought in 90s would still be running as well as back then, you would still maybe want to replace it. Even if it's in perfect condition, right? Boy, that's a strong sell for me considering I drive a car from the 90s. Okay. Maybe not you, right? But do requirements do change?

Maybe if you would be older and lived in the era of radio, hey, radio could still be working maybe, but you still want the television. And television still works, but then you're getting TV channels, but you want streaming, right? So the needs change, even if something is in perfect condition. My car is not in perfect condition. My radio doesn't work, nor do I have the TV, nor can I stream inside my car.

but it gets me from A to B and that's good enough. Let's look at the opposite part of this. If a system is not continually changing, what does that mean? It means that it cannot keep up with those same needs I mentioned earlier, right? Or just to be clear, needs can be on different levels. It could be needs of a consumer or how many consumers you have. If you go back in time at that period,

then you would say, hey, this system is designed to handle 1,000 concurrent users, which is probably like 10,000 users because they're not all the time at the same time, right? You would say, 10,000? That sounds like a good figure, right? 70s, 80s, 10,000. Man, that would be amazing. We can never get there. And now you say that, I mean, you can have a private blog like done in Stots and you will get that traffic.

Needs change on different levels. So let's go ahead and move on from continuing change. I think we can all agree that systems will continue to change. Yes. Or die. Or die. It's one or the other. You choose. Number two is increasing complexity. This might be where two letters come out of my mouth in a minute. As an evolving program is continually changed, going back to number one, its complexity reflecting deteriorating structure, going to what you were just talking about,

increases unless work is done to maintain or reduce it. I honestly don't understand all the words that are in those points, like the deteriorating structure, but I think I get the gist, right? And if that's the case, then yes. Is the 2024 version of this, everything has to have AI in it now. So let's just stuff AI into the existing apps. Correct.

And the key, I don't know whether you did it intentionally or not, is that let's add the AI into existing apps and increase the complexity of those apps, increase the cost to maintain it, to run it, and so on and so forth, right? So we're not talking about, hey, there's this app, and now we're going to focus on something completely different, like AI is a separate, think of it almost as a separate company. No, no, we're going to add AI into this application.

And then, yes, the complexity skyrockets. Not only are we adding AI, we're going to go ahead and just move from monolith to microservices and add AI in at the same time. What could go wrong? Yeah. I mean, at the same time, anything you say that ends with the same time always spells disaster, right? But if you switch from monoliths to microservices, the complexity does not change. I mean, it could change, but you never reduce the complexity.

What you might reduce is the ability to deal with that complexity, which might be one of the next points. I haven't read the article, right? Well, the next point is the fundamental law of program evolution. Long sentence. They knew how to write back in the 80s. Program evolution is subject to a dynamics which makes the programming process and hence measures of global project and system attributes complex.

Self-regulating with statistically determinable trends and invariances. Okay, you're probably thinking I don't understand half those words. I don't understand three quarters of those words. No, no, I'm going to blame you that English is not my native language. So you're supposed to understand that English is your native language. So you explain it to me. Okay, let's see if we can break it down.

Program evolution is subject to a dynamics. It says dynamics, but to a dynamic, which makes the programming process and hence, okay, let's get, let's get rid of some of these things makes the programming process self-regulating with statistically determinable trends and variances. Okay. So I'm going to assume that the way I'm going to interpret this, whether this is the truth or not, as programs change, going back to 0.1 continual change,

As programs change and evolve, they will, by a trend, you'll be able to statistically prove what that trend is. Let's try to make it concrete. I've got a Go app that I'm writing. I've got a microservice. I've got microservices set up. We already know microservices. We know how to write microservices. We know how to, more importantly, operate microservices. Writing microservices are easy. Visual thinking, but go on.

We can tell over time because we did that process. We know that if we need to add new feature X, is that going to be in an existing microservice or we're going to spin up a new microservice? I'm guessing the answer would probably be probably a new microservice, let's say, because it's a new feature. We know how to do that. This is like before Agile, not little A Agile. I'm talking about big A Agile.

Or even Scrum, right? You can look at something, you've done it before, you know roughly how long it's going to take you to do it this next time. That's the way I interpret this point. Yeah, but the example might be wrong, right? Okay, yeah. Give me a better example. So you have application that does whatever it's doing, right? And you want to add a new feature that is not AI that you mentioned. It is some of the old...

or based on the old ideas, principles, what so not. We already did that many times. We know how to do it again. That holds water until you get to the situation, actually, we don't know how to do this. We know how to write Java or Go or whatever we are doing, and we have microservices and so on and so forth. And all of a sudden,

This thing requires GPUs. What the heck are GPUs and how do we get GPUs and what happens when it doesn't work and so on and so forth, right? So if I understood right what you're saying, which is not necessarily true, that would be the case when actually you keep doing more of the same, which I would probably put into the maintenance, right? In my head...

Even when you add new features that could be under the maintenance umbrella, right? Oh, I need one more button in my web page, right? To me, that's maintenance. That's if you're not doing anything truly new, just doing a bit more of the same. I'm going to go back to Matt. Since we're getting this from Matt's blog post anyway, I'm going to go back to what Matt wrote. Matt wrote for point three, Lehman sums it up here with the fundamental law. Requirements outside business requirements and marketing forecasting affects a program's evolution.

The people, processes, and software itself all play a large role. I'm still confused. Me as well. I mean, I don't even know what requirements outside business requirements. This is... We could be speaking now in... Choose some other language. I will be equally confused. Let's move on to the next point, number four, because obviously, if you can go back and read this, go to the Slack workspace. This is episode number 288. Leave some comments there and tell us how dumb we're being. This sounds very much like

Long time ago, I said, I'm going to read Shakespeare in original. It did not end up well. I did not understand the language, man. Let's go to this next one. Number four is conservation. The word is conservation of organizational stability during the active life of a program. Okay, I think we're good up on that one, right? During the active life of a program. We're both in the same point. The global activity rate in a programming project is statistically invariant.

I was good up until those last two words. If they would never finish the sentences, it would be so much better. We need to run this back through an LLM. It's like, say this to me like I'm a fifth grader or a third grader. Exactly. Right. Just explain it to me like I'm a third grader. So if I actually was doing this, I could have done that, but I didn't. I read this as a result. This is going back to Matt's blog post. I read this as a result of the Mythical Man Month. Good book. You should go read it. That certain projects limit how many resources can be allocated to them.

Okay, that we can agree with. Yes. Let's take Kubernetes. That's a nice little small project. You can't put 1,000 people on Kubernetes and make it ship any faster. Let me rephrase that. You cannot add an extra 1,000 people to Kubernetes project and have it ship any faster. Yes and no. Kubernetes is the example of, and I know that I sound like a broken record of

kind of microservice architecture in terms that, hey, there is a controller, separate application in a way that manages PodSchool. There is another one, replica set, separate application, separate controller, code base, what's on it, and so on and so forth, right? So it's split into small pieces. Now, I don't know whether you can reach 100 or 1,000 or 10,000 people working on it effectively. That I don't know. But you can be more effective

the more you split it into smaller pieces that are independent of each other. So let me put it this way. There is a limit how many people can effectively work on a single code base. Would that make sense? And if you want to speed up things, you need to split the code base.

Into two, three, four, five. Now, that does not mean that you will be exponentially speeding up, just to be clear. Oh, you split it into two, then you put double the people and you have double the velocity. Not, but you can increase the velocity with more people if you speed it up. Once you reach that limit of, hey, more than 10 people is noise. It's not productive anymore, or whatever the number is. Unless you're just adding management layers, and then that's really productive, right?

Yeah, that's why we learn to ignore them. I mean, I have a single person working on a code base and that single person has up his tree eight managers. Yeah. No, nine managers because ten people is the limit to work on a project. Oh, right. Yeah, so nine managers, one person doing the work. We'll leave that there. The final point is conservation of familiarity. So far, so good, I think. During the active life of a program,

Again, we're good with that. The release content, changes, additions, deletions, of the successive releases of an evolving program is statistically invariant. Okay, look, I have to go and look up what does statistically invariant mean? Because it's one thing to not understand it, but to...

I'm guessing so, but you better Google it. Well, I'm Googling it, and it's not making much better because it says, invariance is a mathematical term for symmetry, and many statistical problems exhibit such properties. Oyoy. Okay. At some point, we'll figure it out. If you want the explanation below. We'll look at the explanation from Matt. A project changes proportionally. Small projects can change drastically, and large projects cannot. Parenthetically, within reason. Exactly. That makes a lot of sense.

You think about your hello world. Like for me, when I'm starting a new project, I get a hello world running as quickly as possible. Yeah, because the second hello world needs to take into account the first hello world and the third hello world needs to take into account the first and the second and so on and so forth, right? So basically, there are more things you need to consider in order to add a feature, right? True.

But the reason why I try to get to Hello World, a running Hello World as quickly as possible is because I come from an operations background as my first and not a development background as my first. So I tried to get a project up and running in a real environment as quickly as possible because I know if I can make that process with at least basic CI, it may not be actually running Jenkins or any other tooling. It may just be, okay, do I have a batch script? Can it copy over and can it start?

Is that basic to where other people can start consuming it? Because if I have that process down, I'm not going to be chasing that three weeks, three months, three years down the line. And we're just adding features. And as soon as a feature is added, it goes out. So I consider that baseline for me. But once it gets to a certain point, then it gets to be a little more challenging because I think about, okay, something was running great this way. And then all of a sudden,

We've now moved from running it nice and locally, self-contained, Spring Boot app, and now we have to deploy it inside of IBM WebSphere. All of a sudden, everything got really hard, really fast. And it gets harder with time. And it gets harder with time. Going back to number one, continual change. But this is interesting. Matt's other point that he had on this fifth point, software becomes more stable over time. This is a key point. As feedback is incorporated into the system.

That's true. So let me rephrase it. It could be true. So if outside conditions are the same, it would be true. If you don't increase the user base, and I'm using that as an example, there are thousands of other variants. If you don't increase the user base, it will become more stable over time. And if they don't come up with new requirements, it will become more stable over time and so on and so forth, right?

But that does not reflect the change that was mentioned as a first point, if I'm not wrong, right? So let's say that we finish the project and say, this is it. From now on, we just fix issues. No new features, no new users, no new requirements, nothing. We just fix the problems.

If that's the case, then yes, over time it will be increasing stability, right? It should be, yes. But that means that if we are going bankrupt, it will be more stable over time. So it just won't be running. No, because we're not getting new users and they're not requesting new things.

And just those five guys or girls that are the users of our product, they're dead. And they don't even have a way to contact us to request anything except to fix an issue. That's the only thing that they're allowed to do. And they will stay with us forever. Yeah, I think that holds. Let's apply this to Kubernetes, just because we already talked about it once. So we've gone from 11 to 12 to 13 to blah, blah, blah, to now we're at 31.

Is Kubernetes becoming more stable over time or less stable over time? More stable over time. Why is that? Because it is not introducing new stuff with such velocity. It is much more focused on stability, let's say. I mean, I'm not saying that nothing new is coming, right? But it's more or less stable and there is much bigger focus on keeping it stable than it was before.

But let me ask you a question, right? Do users of Kubernetes find their systems more stable over time or no? Sounds maybe like the same question, but it's not. Because over time, you're introducing, oh, now this month we're going to put service mesh because now we need TLS or this or that. And we're increasing from five nodes to 500 nodes and so on and so forth, right? So the

challenges, let's say that maybe on average statistically are the same. They're changing all the time and we might be stable in terms that we are not more lost than we were before, even with new additional challenges because we solved some and then we got some new, but not more stable. From a user perspective, Kubernetes itself, yes. I mean, you can say, is Linux more stable? Most likely, probably.

than it was 15 years ago. Do we do more with it than we were doing 15 years ago? Oh, yeah. I think the point for both Linux and for Kubernetes is they are both removing things on an ongoing basis instead of just piling on more and more Frankenstein monster-level items. Yeah, but...

You know, when you look at Fun Piece, so I think that the point I'm trying to make is that if you look at Fun Piece in isolation, that holds true. And probably was in the systems like 30, 40, 50 years ago, right? But we keep piling more pieces to the pile. Even though if each piece is more stable than it was before, we have more of them. It's like Jenga, whatever it's pronounced, right? Yeah.

That piece over there, brilliant. It's at the bottom. It's just that we added 57 more on top of it. And we need to take that one off the bottom and put it up on the top because it's getting touched again next week. Yeah, because, you know, until yesterday, we did not need GPUs. Who needed GPUs? Nobody. Now we do. So now we're not talking anymore about CPUs only, but we're talking about CPUs and GPUs. That's making it less stable because...

We are increasing complexity, right? Is there any way for us to stop increasing the complexity? Yes. Stop increasing business. Just say, this is it. Nobody can request anything. Nobody can join anymore. That's it. Recurring revenue, whatever it is today. We're going to make it by law that nobody can leave either. Just to be clear. So stop accepting new signups. Don't allow people to leave.

It sounds like Hotel California to me. Yeah, exactly. It sounds like phone companies where I come from, at least before. That's true. Phone numbers used to not be portable. Can you imagine that? Well, I can. I am old enough that I can say yes. So there was a time, boys and girls, where a phone number was actually tied to a physical device that was on the end of copper. Yes. You could change the device.

Well, no. There was a time where you couldn't change the device. Oh, okay. So, yeah, you're older than me. I come from the time where you could change the device, but you couldn't change the house and keep the number. Yeah, there was a time in the 60s and 70s where you look back on it now as like, how do we even survive? And then what's going to happen now, 40 years in the future, and people are going to be saying the same thing. It's like, man, I don't know how they got by in the 20s.

Wait, let me do them at 40 years. Yeah, that's the end of my time. I'll be close to 100. Yeah, I don't care. As long as you still have your same phone number, you'll be okay. I think that's what we're seeing here. What comes after me, not my problem. Yep, and Kubernetes will be at version 1.43, 1.20, 1.50, 1.60, or 1.160. I can say with absolute certainty, long before that, Kubernetes will be replaced with something else.

It won't reach that number. I think it will reach that number because there are still new versions of mainframes being released today that were being released in the 60s. Okay, so let me put it this way. I will not know that there are new versions of it. That's correct. Just as I don't know that there are new versions of mainframe. That's what we're talking about. We tried our best to work through this. English failed me today. I wish I could read math better.

These were a lot of math phrases that just didn't make any sense. I used to know math 40 years ago. Not anymore. In all seriousness, all those, call it laws or fundamental unchangeable things, do not last forever. I'm pretty sure that I could debunk most of them if only I would understand what they mean. True. But I think this first one is going to be always true.

continuing change. Let's reread this one because this, I think this is the key one. The others get a little weird to me, a program that is used. And that is as an implementation of its specification. Let's simplify this. A program that is used reflects some other reality undergoes continual change and becomes progressively less useful. I cannot agree with the last part. I'm not too much sure what it means by that kind of, I mean,

The only reason why we're making all that change is to make it more useful. If you have continuous change and the end result is that it is less useful, I think you have a serious problem. Matt's take on this was this law tells us that a program is never really done. That I agree, but less useful? There are two possible explanations for this blog post. Either I have no idea what those words mean,

Or Matt, is it Matt, the name of the guy? Matt, yeah. Matt is taking a lot of liberty over there in interpretation. What do I think about continuing change? Let it be like this. I don't see a way how he can explain less useful with that sentence. If a program becomes less useful over time, that means A, business requirements were not gathered correctly, and or B,

Whoever was developing from those business requirements did not do what the requirements said to do. Or the most likely scenario, your requirements are bad. It did not reflect what people need. Get your requirements right. Then you'll have something, hopefully, that is useful to the earned users. No, no, I have a different law. Acknowledge that your requirements are going to be wrong and that you will realize only when you release it to the users and deal with it.

Because eventually you might do it right. Eventually. That's my experience from startups. Tell me, I don't know how many startups you've witnessed yourself, Darin, but tell me a startup who gets it, who figures out the requirements from the first, actually from first couple of years. Many of us never figured it out even at all, ever. Very few. We can probably count on less than two hands.

that have gotten it right out of the gate. The link to Matt's blog post is going to be down in the episode description. Then you can also link off to the original article from Lehman. I would recommend reading it, maybe run it through your favorite AI to help simplify it, put it into terms that other people can understand in the 2024s. And then head over to the Slack workspace, go to the podcast channel, look at episode number 288 and leave your comments there. We hope this episode was helpful to you.

If you want to discuss it or ask a question, please reach out to us. Our contact information and a link to the Slack workspace are at devopsparadox.com slash contact. If you subscribe through Apple Podcasts, be sure to leave us a review there that helps other people discover this podcast. Go sign up right now at devopsparadox.com to receive an email whenever we drop the latest episode. Thank you for listening to DevOps Paradox. ♪