Why software keeps breaking? (Lost Episode)

ThePrimeagen (0:02)

Hey, we're doing a quick bonus episode of The Standup. It's gonna be short, it's gonna be hot, it's gonna be spicy. Casey is gonna give us kind of a thesis on the change of software and where things are going and perhaps kind of his thoughts on the web world and on the programming world.

Teej (0:17)

Why does software always break?

ThePrimeagen (0:19)

Eeyah, eeyah, eeyah, eeyah, eeyah, eeyah, eeyah! Anyways, I'm sorry. Casey is gonna give us a thesis on why does software always break. Casey.

Casey Muratori (0:30)

This is a hot new thesis, no one's ever seen it before. Except I posted it back in 2021

It's just gotten more true since then, Casey.

ThePrimeagen (0:41)

It actually has gotten more true and reposted.

Casey Muratori (0:45)

So essentially what I wanted to try and point out to people, because I don't think that this is appreciated enough. We talked about it in the previous episode of The Standup that we did, where I was saying like, a lot of the things that I see people saying positively about AI coding, I don't necessarily disagree with. I just think they're not including this really important other part, which is that a lot of the things that people are talking about doing with AI, are things that no one should have had to do in the first place. They're being done because we've created such a bad programming environment that nobody wants to interact with it anymore. It's always breaking, it's always changing, it's got way too many layers of abstraction. Most of those layers don't work very well. There's way too much complexity, like all this stuff.

It makes perfect sense why someone reached for an answer, because why do you want to do it?

I just want to talk about a separate part of that, which is just the very unreliable nature of software nowadays, and especially builds, like it's like, okay, I got this piece of software that I wrote, and what are the chances that I could compile it again in six months or something, or a year, or two years, right? Or even not even compile, what's the chance that it'll run still if it uses things like REST APIs with some web service, right? So I've got these different web services I'm using, so even if I don't have to recompile my thing, or even if it's an interpreted thing that runs, and I'm keeping the same version of the interpreter or whatever else, it's going to make these API calls out to web services and those services could change. So what I did, and hopefully we can put the graphs up as I'm talking about them, but I posted these on Twitter, they're very simple. It's just taking the fact that, look, if you assume, and I say this in the tweet stream, that if you take the chance that something will remain working after a year, is some probability, so like 90 percent chance that this Twitch REST API that I'm going to call, a 90 percent chance that they will have kept it the same a year from now, so that it will still work. My app sends this REST API call out to Twitch, it expects certain response back, and they're not going to change it in some breaking way in a year. If we assume that we just have some probability, like 90 percent for that, that we can pick, we just imagine one, or we don't have to measure, just imagine your head 90 percent or something like that, then the chance that your code remains working after x years is just given by p to the x times n, where n is the number of those calls to things that you have.

So you can graph this. And what I showed is that if you had a 99 percent chance that every API call you use, 99 percent, which is way higher than anything in the web world typically has after a year, but 99 percent across all tools, the graph still looks pretty bad. Right? You look and you look at it, it's like, okay, after a year, it's like it still looks pretty darn bad. It goes down pretty rapidly based on the number of tools. So you can see the graph I show is like one tool, two tools, three tools, four tools, five tools, it goes down. I love that book.

Teej (3:46)

It's a Dr. Seuss book.

Casey Muratori (3:48)

Yes.

It's a great book.

It's he captured. Dr. Seuss was a lot of people don't know that he, the doctorate that he had was in computer science.

Teej (4:00)

He was software engineering. He was one of the few to become a professional engineer in software, as opposed to the rest of us.