Matt Godbolt: Hey, Ben,
Ben Rady: Hey Matt.
Matt Godbolt: We, uh, we haven't really thought about this, have we?
Ben Rady: No, I mean, not really.
Matt Godbolt: We, we just said, Hey, let's talk about technical debt. Yeah. And then I said, "Hey, Ben", and that's as far as we've got .
Ben Rady: That's the extent of the planning.
Matt Godbolt: Thta's the extent of the planning. So let's talk about technical debt.
Ben Rady: Yeah. Well, I mean, I think I, uh, you, you, you may know that this is a little bit, it's not hard to get me on a soapbox as our listeners well familiar with at this point. And this is one of those things that I am very happy to, uh, soapbox about, uh, which is a new verb that I invented just now to
Matt Godbolt: To soapbox?
Ben Rady: Yes
Matt Godbolt: I could get behind that,
Ben Rady: Excuse me while I soapbox. Um, because I think, uh, it is, it is a metaphor, and it is, it is something that has, um, people have, have lost what the original intent of this metaphor was, what the original meaning of the metaphor was. And it has become a thing that it was never intended to be. And I, I think it's an, actually, it's a harmful thing in its current sort of, um, colloquial understanding of what it means. Well,
Matt Godbolt: So why don't, why don't you define technical debt from the point of view of the original idea where the, where's, where does the, the term come from?
Ben Rady: Right. Well, the good news is that I don't actually have to define it because Ward Cunningham is the guy that invented the term and he defined it. And we can link a video, uh, a YouTube video in the show notes, uh, to Ward's definition. Right. He explains what it is.
Matt Godbolt: What's the TLDR of that
Ben Rady: I'm not gonna recount the entire video here in the podcast, uh, for copyright reasons, if nothing else. But, um, the d the idea behind the technical debt metaphor was, uh, ward was trying to explain to people who were not programmers that their mental model of a software system would change over time. Their understanding of a problem would change over time. And, you know, they would design a system for the problem as they understood it, and then that understanding would change, and then they would have to make changes to the design. Mm-Hmm. , uh, in order to accommodate that new understanding and the difference between the current state of the system and sort of like the, uh, you know, design as it would reflect their current understanding of the problem he referred to as debt, as technical debt. And he wanted to use that metaphor as a way to you know, tell people, it's like the longer that we put this off, the more expensive it gets. Right. Like, we have to bring the state of the design of the system up to our current understanding of the problem, otherwise it's gonna get more and more expensive.
Matt Godbolt: Um, and that is quite different from the way that certainly I colloquially use the term technical debt.
Ben Rady: Right. And, and in, in this video, actually, Ward is very explicit to say, at no point did I, uh, imply or recommend that anyone write bad code and then go fix it later. Right? Right. That's not what the metaphor was intended to describe. I don't think you can go faster by writing a bunch of bad code and then fixing it later. I think that's a slow way to program. Uh, this was about evolving a design as your understanding of the problem evolves. And if you don't, uh, you know, put in the time and effort to evolve that design, then the cost to change your system is gonna get more and more and more and more like, like interest payments on the debt. Right, right. Um, I think one of the reasons why, uh, Ward's original definition got lost is that very few people actually designed their software that way. ,
Matt Godbolt: Right. ,
Ben Rady: Very few people are actually, we were talking in a prior episode about incremental.
Matt Godbolt: I was gonna say, it seems to sound very..yeah..onn theme for that.
Ben Rady: Yes. Iterative, right? Like, oh, we're gonna, we're gonna design it the best way that we know, and then we're gonna learn more, and then we're gonna redesign it, and then we're gonna evolve the design. We're gonna use refactor and change the design. That's a skill, that's a skill that not a lot of people have. And even the ones that have it don't necessarily use it all the time. And so, like, I think the ward's original definition is actually much more narrow in its applicability than the term is used, or the term is used all the time for, for basically as a, as a metaphor for, it's not a metaphor, it's just like, that's bad code, right? When people say technical debt, they just mean bad code, and they're not particularly specific about what they mean when they say that it's bad. Um, and I think some of that is maybe hidden by the metaphor, which we can talk about about, but I think that's sort of like what the original definition was. I think that is, Ward's original definition is a very useful definition. I think it's a little bit more narrow in scope.
Matt Godbolt: Very much so. Yeah.
Ben Rady: And it's, it's something that I, you know, it sort of like makes me wince every time I see someone use it in a, in as a, as basically a, a, a synonym for that. Well, that's code. The code is bad and I don't like it.
Matt Godbolt: Right. And I think that's, that's the thing that you were saying, like prior to us recording that is, as you say, it makes you wince. It's, it's when people start, like building around something and saying, this is technical debt, and they're sort of poking it with the barge pole further and further away from them. And then saying like, well, we don't go there because it's, it know, it's full of technical debt and it either gives you an excuse to ignore problems or it gives you an excuse to write even worse code. Mm-Hmm. to keep dog piling on. 'cause you're like, well, it's just more what's more debt? You know? It's like you've already essentially technically bankrupt, uh, yourself, uh, and the interest, you can't keep up the interest payments. So you're like, why even bother trying, you know? We were just, just Yeah. Just another hack on a hack that at least from, again, that's the colloquial Yeah. Understanding of technical debt here, which is not what you've just described wards, um,
Ben Rady: Right, right. Absolutely. Definitely was. Um, and I think another problem with this is that, you know, the, and, and I don't know, I doubt very seriously that Ward anticipated all of the impacts of him just sort of coming up with this idea. Um, but one of the, the unfortunate negative impacts I think of this is that to most, uh, people who run businesses, debt is not a bad thing. Debt is a great tool, right? You, you take on debt for lots of good reasons, right? Um, so it's like, yeah, okay,
Matt Godbolt: We'll take on some, debt you take it on advisedly, right? Yeah.
Ben Rady: Uh, even if it's sometimes kind of high interest, like, you know, if you're, if you're starting a new venture and you need to move quickly, that's like, yeah, we'll take on a bunch of debt. Like, that's fine. So like, you know, the, the way that people, you blend those two ideas together, right? Mm-Hmm. , the, the misunderstanding of technical debt as bad code and the sort of financial application of debt as a useful tool. Uh, you wind up with this weird intersection, which is bad code is a good useful tool, right? Yeah.
Matt Godbolt: Right.
Ben Rady: Which at no point does anyone who created this term even coming close to implying, right? Right, right. So it's sort of like becomes this like received wisdom of technical debt received from who with what purpose. Right? Right. Um, it's, it's, it's the worst sort of argument from authority where you didn't even understand the original argument from authority
Matt Godbolt: . Right? It is, it is completely, there's not even like a coherent, um, thought process behind it because it's a phantom, uh, idea. No one actually made this point. It was, right.
Ben Rady: Yeah. Right. But
Matt Godbolt: I guess it, it's, it's entered the zeitgeist of programmers. Mm-Hmm. , right?
Ben Rady: Yes. It has.
Matt Godbolt: So we're, we're kind of stuck with it whether Ward meant it to mean this or not. When people colloquially, like nine times out of 10, if I'm talking to someone else, I'll be honest with you, I'll be making you wince by saying, you know, Hey, we've got that error. Like, you know, I'm working on something right now. They're like 2000, uh, parallel pieces of work that I'm doing across a multitude of days. There's all sorts of broken bits of data and things that I'm having to deal with. And if one or two of those things fail, I'm like kind of okay with it right now, because on aggregate, that's still useful for me. Mm-Hmm. . And in my mind's eye, I am like, I want to chase down every single thing. I need to understand it. For all I know. The reason that day one dies, uh, you know, crashes out is actually a systemic problem through the whole code base, right?
Matt Godbolt: And then it's just that it doesn't crash on the other days or whatever. Um, but in order to move forward quickly, I am, in my mind, I'm filing that under technical debt incorrectly and saying, I'm gonna move on. And we'll come back to it a bit later because I mean, and maybe you could argue this is part of the, and I'm gonna try and swing it as part of the, uh, progressive, I can't remember what we came up with , uh, iterative way.
Ben Rady: Yeah. Yeah.
Matt Godbolt: I wanna get to the end. I want to get my 2000 days broken or not broken, and then say, well, the next stage of the pipeline is to do this thing. And I think it's this, but I don't know that it's this, as in, I don't even know what the design should be or what the facilities I need to pro produce are.
Matt Godbolt: So I'd rather get there with some amount of like, brokenness Mm-Hmm. to explore the space, solution space of the next part. And then as actually two more pi steps after that. I'd rather get all the way and then go back to the beginning and go like, okay, these things need to be looked at. Now, the, the, these warnings that we're seeing, or these crashes we are seeing are a symptom of, in my mind, the technical debt that I'm paying down. Mm-Hmm. . Mm-Hmm. . But , you know, you know, it's so easy to to, to go like, oh, yeah, yeah, yeah. It's just bad code. I don't think my code is bad. It's just these are right. These are, these are bugs. These are issues that I have got tracks in GitHub or whatever. Yeah. And I know I've gonna come back to them.
Matt Godbolt: They're just not high priority right now. And I, but they, they could, could be something that actually is really important to look down. Like, for example, I'm gonna give you an example that's literally just happened right now. Yeah. Yeah. Um, we had a, an issue with, uh, uh, uh, a timestamp that fast forward itself into the future. It was like 150 years in the future. Suddenly we know we're processing data from 2022, and then suddenly it's the year 2187, and you're like, oh my gosh, what the heck's happened here? Um, I had seen it once and I'd filed a bug and I couldn't reproduce it, and I let it sit. Now, obviously, that's kind of like, there's something wrong in the system. Everyone knows there's something wrong in the system. Mm-Hmm. was it, uh, a corrupt file for one day ever. Who knows, right?
Matt Godbolt: I certainly didn't at that point in time. Um, and then we let it lie, uh, you know, it happened again, one more time. We put, added something to it, but no one really tracked it down. And then today we had a completely unconnected issue where we ran outta disc space. Mm-Hmm. . And the reason it turns out now we know that we ran outta disc space, is that some poor process was trying to fill in all of the gaps between 2018 and 2,187 with, with just empty data. 'cause it's like, oh, well, you know, Mm-Hmm, , I have to do like a forward fill of all this data, and it ran outta disc space doing so understandably. And of course then we're like, oh, wait a second. Where have I seen the year 21? Oh, I know. This is that bug. And all this time that has been sat there, and actually we've processed other data incorrectly. So we found the problem, we've fixed it, and now we cursed to actually go back and, and reconvert a whole bunch of data, which is, you know, expensive. Mm-Hmm, . Mm-Hmm. . So that did not pay off . That that Right. That came back to haunt me. Um, but sometimes it doesn't. Right. Am may, am I right to, you know, stop and drop and do everything every time? I don't know where No,
Ben Rady: No, no, no. And, and so the, here's, here's the thing about this is that this, the problem, the reason I wince is not because I'm trying to advocate that everyone should do everything perfectly all the time for some definition of perfectly. That's not what I'm saying at all. What I'm saying is, is that why are we using this broken, misaligned metaphor, right? That to talk about, call about things that we as programmers can be much more specific about and have much more precise terminology about. Because when I hear you say, this is technical debt, that doesn't really align with the other things that I see people call technical debt. Yeah. 'cause at least in my mind, those are, those are very different things with very different impacts on the system and the reliability of the system, and the long-term viability and the pro everything else.
Ben Rady: And so the the ways that I kind of, the dimensions that I think about when it comes to these sorts of things, and this is something that has definitely been evolving in my mind over the last few years. You know, it's not, this is not like some, you know, uh, received wisdom as, oh, everybody knows this has been around a long time. Is I, I, I've been, I've been trying to like say, okay, Ben, well, technical data is not the right way to think about it. Then what is, and the more modern thinking that I have on this is that you should think of your system in terms of, uh, complexity, uh, its capabilities and its risks. And so what I hear you describing here is actually just a risk. Mm-Hmm. There's a risk in the system that is unaddressed. Yep. And it can make very good sense not to address all of your risks.
Ben Rady: I mean, this is true in every endeavor of engineering, right? They don't make somewhere, you know, bridges that are like impossible to fall over because they would be cost prohibitive. Right. There's a certain standard that they designed to, and they say that it is, you know, it's gonna fail under these conditions, or it's gonna fail after this amount of time if it hasn't been maintained. And there are, you know, risks that, that you carry, um, in the operation and the, and the construction of that bridge. And those are deemed to be acceptable for whatever, um, application it is that you're doing. And it's no different in software, right? Mm-Hmm. . So you have risks that are in your system, and it is right and proper for you to make a backlog of those risks and account for them, but it's not necessarily right to just always fix all of them as soon as you possibly can. Right? Right. Um, so that's one dimension, right? Yeah. And that is a very different thing than technical debt.
Ben Rady: That gets lumped in, in the same, which we're talking about this metaphor of technical data, and it means basically bad code. And what it means is, oh, it's a risk that we have, you know, if the disc fills up, if this problem occurs, if we see this exception we've never seen before, whatever. Right? So that's one thing. Yeah. Another thing is capabilities. Just new features, new functionality. Now, I, I've definitely used the term capabilities more and more, uh, working where I do, because features means something totally different.
Matt Godbolt: , I mean, features means about three different things to three three people within our organization. So Yeah. Capabilities and facilities and whatever we all come up with, like alternative
Ben Rady: Functionality. Yeah. Right. Well,
Matt Godbolt: Similarly, for what it's worth, um, we always talk about, you know, if you talk about the, uh, if you sort an, an array of things, they are ordered. But if we talk about, you know, the ordering or the order or, you know, what order are they in, um, again, in our world, order means something else. There's an order. Yeah. Right? So I always say sequenced. Now are they sequenced in this way? Are they in a, yeah. So you kind of learn these ways of avoiding ambiguity in your day-to-day based on the sort of colloquial expressions that are more common than the perhaps Yeah. More common in Yeah. General English ways. Yeah. Anyway.
Ben Rady: Right, right. Yeah. I mean,
Matt Godbolt: So anyway, the facilities, yes. Facilities, no capabilities.
Ben Rady: Capabilities. The capabilities, right. It's the things that your software's capable of doing. Yeah. Right? Yeah. And you're gonna have gaps in those capabilities. Sometimes those gaps actually represent risks. Like, oh, if this thing happens, then we won't handle it and it'll crash. Yeah. Sometimes the gaps in the capability are just like, yeah, we just don't do that yet. Right. That's not something that the system does for you. Right.
Matt Godbolt: Literally before coming, and I know we said about this bug we found, but I was adding the capability of our cache directory to have a maximum size, which at the moment it doesn't. And we've been working around it by every now and then you just rm -rf /tmp/whatever you know, my cache, whatever. And we're like, we've kind of been fine with that. That's a capability we could live without, but it's annoying. Mm-Hmm. . And now you go, I'm like, well, we can add that capability. So that's, that's fine. And yeah. Right. Okay. Mm-Hmm. capabilities.
Ben Rady: And then the third thing is complexity. Now, we, I think we've talked before in the show about complexity, necessary complexity versus unnecessary complexity. Um, I think it's good to minimize unnecessary complexity, but I think the thing that you really just sort of wanna be looking at is the total complexity, whether it's necessary, whether it's unnecessary. It's still there. It's still makes your code harder to understand, harder to change. Right.
Matt Godbolt: Um,
Ben Rady: It doesn't really matter if it's perfectly designed and is the absolute minimum thing that it could possibly be, it's still complex. Yeah. Yeah. That still has costs, right?
Matt Godbolt: Absolutely. Yeah.
Ben Rady: And so these are the three, three dimensions of software that I, I, I kind of think about and I try to, whenever I think about technical debt, I try to think about, okay, is this a risk? Is this missing, uh, capabilities? Is this complexity? Like what is this more specifically, I don't need to use a metaphor, a financial metaphor to reason about this. I'm a programmer, I'm talking to other programmers, I can be more concrete. You
Matt Godbolt: Can say these things. Yeah. And you are right. A lot of those things. So what I'm hearing from you is that, um, some of the, I mean, 'cause every, we can make up a straw definition of what other people think technical debt is in a second. Mm-Hmm. , because I think that'll be useful. But Right. What you are now is saying is like within, at least the people we talk to, when people say technical debt, they're probably better served by thinking of it in one of those three categories. Mm-Hmm. . Because we are assuming they don't mean my code is just terrible. And that's okay. Right. Which is the other, again, now this is the straw man.
Ben Rady: Well I would put that in unnecessary complexity, right?
Matt Godbolt: I mean, yeah, you're right. I mean, I, I could make an argument that that just complexity of its own is not necessarily, you know, there is, while bad code can be unnecessarily complicated, it can also just be simple and bad and wrong.
Ben Rady: Mm. Well, yeah, that's,
Matt Godbolt: You know, sometimes you have to add complexity to make, uh, make it better. You know, like, Hey, I've got this really simple bash script and this bash script is, uh, you know, and you're like, but that's why are you doing it in bash? You're like, well, it's sort 'cause it's three lines of bash. And you're like, but if it, there's no monitoring, there's no, there's no email if it goes down that I can't parallelize it. All these things. I guess those are capabilities and things like that, but it's not bad. Uh, yeah, I dunno. Yeah, you're right. Now you're . Listener, Ben is grinning the I told you so grin at me right now. .
Ben Rady: Well, I mean, I'm bringing all these things up again, this is something that I have, uh, I have been thinking about for a while, and I don't know that, I'm not trying to actually say that this is some new comprehensive way to think about it. I'm just, I'm trying to figure out a replacement. Like I know that technical deck is wrong, and I keep thinking about like, okay, how can I be more precise about this? Right.
Matt Godbolt: I mean, first of all, um, I, we should note that Perry [Ben's dog] has just made his first podcast appearance.
Ben Rady: Oh, has he?
Matt Godbolt: Yeah. He is behind you right now. So Ben's dog came in, I'm sure he saw it, and I did not invent that. Maybe he left you, I
Ben Rady: Mean, did he walk back out again? I,
Matt Godbolt: Yeah. I didn't notice him go out, but I thought I was like, Hey, it's Perry . Yeah. You know, we've had Monty make a debut, although he's asleep behind me. Uh, is he not? No. All right. Now I've just made you look around.
Ben Rady: He's probably somewhere in here. I don't know.
Matt Godbolt: Anyway, um, I've now forgot what we were talking about, . Well,
Ben Rady: It's, it's, you know, can, can am I, is, uh, I'm trying to find new tests for my hy uh, my scientific theory here. Right? I'm alright. My hypothesis is that you can categorize, you can take what currently falls into the very vague category of technical debt, and actually a little bit broader than that. The sort of like the aspects of software that you need to care about when you think about technical debt and like good code versus backup and things like that. Right? Right. And fit them into one of three categories. Is it a risk, is it capability, or is it complexity? And complexity has a necessary and an unnecessary component Right. To it. Right. Got it. Um, and I will say that, like for me on the projects that I'm working on right now, these things are actually fairly directly measurable. Right. If you wanna see my risks, go look in the issue backlog. Yeah. All the risks that we know about are in there, right? Yeah. If you want to see the current implemented capabilities, look at the tests, all the tests, describe all the capabilities of the system, and you can see what they all are. Right. If you wanna know the missing capabilities, well, that's probably also in the issue backlog...
Matt Godbolt: The issue tracker.
Ben Rady: Yeah. And if you want to know what the complexity is, you can do a lot worse than just counting the number of lines of code
Matt Godbolt: .
Ben Rady: Like there are other more sophisticated ways code to metric complexity,
Matt Godbolt: Not a bad proxy.
Ben Rady: It's not a bad measurement of complexity. Yeah. Right. Yeah.
Matt Godbolt: Yeah. Fair,
Ben Rady: Fair. Uh, and so that's sort of the way that I, I I think about it when we think about like the, okay, we could mitigate this risk. Mm-Hmm. , but is it worth the complexity? Yeah. Right. Maybe it's better just to wear the risk and like, even if it happens once, it's like, yeah, you know, it crashed. We turned it back on again. Wasn't great. Yeah.
Matt Godbolt: This is a, a bit like that sort of pragmatic thing where if you, if you can't write a test for it, make it fail fast, you know, like there's a, there's a trade off there. It's like I could spend a tons of complexity testing the every command line parameter to my command line tool. Mm-Hmm. Or the first time anyone notices that we, that dash dash whatever doesn't work anymore is like, we go fix it. I mean, again. Right. You don't wanna Yeah. Yeah. Right.
Ben Rady: So 'cause 'cause I feel like unless you have those ways to discuss the trade-offs, which you wind up getting into, is this sort of like semantic argument about like, oh, that's technical debt, it's terrible. And you're like, no, that's just a reasonable trade off. And it's like, Mm-Hmm. , what are you trading off? Right? Like, if you can't describe that, if you can't enumerate that, it sort of falls into this vague definition of it's just bad and I don't like it.
Matt Godbolt: Yeah. Yeah. And there's a lot of, yeah, we've, we, we've talked about FUD sort of before Mm-Hmm. about, you know, there's a lot of fear, uncertainty, doubt. You can use it as kind of like one of those words, but once you've painted it with that, it, it's like you, you know, it's just, it's just bad. Unequivocally bad. Mm-Hmm mm-Hmm. . Um, but one thing that's I think, I think missing, and maybe this is maybe you're, you've gotta, I could imagine maybe you're a talk to this, but like, is there is something really emotive, which is perhaps the problem with the term technical debt, because I think everybody, even when you're talking about engineering stuff, everyone can kind of get your head around the fact that debt has a compounding aspect to it. Mm-Hmm. . And not all of the things that you've said have a compounding aspect to them.
Ben Rady: No, that's true.
Matt Godbolt: Yeah. Missing capabilities don't necessarily have a compounding aspect. It's like, oh. I mean, they could do, don't get me wrong. Yeah, yeah. Um, the, the, uh, risks could be compounding. You could imagine a risk, which is like, well, if that happens then oh, now all these other things become really important. You know, suddenly, like, you know, if you can't, if you can't reproducibly recreate all your data from scratch, then this, this bug that you have that you've seen once that can corrupt a file might be very, very, a big, a big deal. Because suddenly you might have to go through, you know, hundreds of thousands of terabytes of data again or whatever. Mm-Hmm. . Right. That can compound. But almost always code complexity has a sort of in your face day on day Yes. Uh, compounding effect where it's like, yeah, I wanna add a new capability.
Matt Godbolt: Oh, but the code is too complex. Right. And it's sort of like, it gets worse and worse and worse. 'cause it's like what you're really talking about is sort of entropy of the code base. Mm-Hmm. . And it just, it, it gets worse on its own somehow. Right. You could go back to a project from two years ago and somehow it's worse than you left it, you know, bit rot is real. Yeah. Yeah. So it feels like that there's sort of some, and again, it's emotive rather than like, uh, you know, I can't put my finger on it. As you, as you say, if we're talk about professionals talking to professionals, I think we all understand that that is already present. If I just say, yeah, the code is unnecessarily complicated, you can say, yeah. I guess that makes it a pain to change. You're like, certainly does. And, you know Yeah. That, that, you know. Right. Well, we don't have to say, but it's a debt.
Ben Rady: Right. Right. But
Matt Godbolt: It does. Yeah. But it's so easy. It's a trap to fall into. I mean, I, I can, yeah.
Ben Rady: It is a, it is a trap to fall into. And I think if you go back war's original definition and think about, about what he was actually talking about, he was talking about unnecessary complexity in my model, right? Mm-Hmm. , he was talking about like, the problem has our understanding of the problem has evolved beyond the current design. There are things in the current design that don't fit that problem. And it could be like, you know, literally just code that isn't used anymore. It could be designs that really aren't, um, applicable for the problem that they're trying to solve. And you sort of like twist them around to try to get it to work. And it's just adding a bunch of things that you just don't need. And the solution to that, or, or a way to address that is maybe a better way to think about it, um, is to refactor the code so that the design better fits the problem that you have.
Ben Rady: And hopefully just sort of shrink the number of lines, but at a minimum just make them easier to understand. Right. Yeah. And again, this sort of gets back to my thing of like, that is a very narrow thing. Word was talking about a very specific type of unnecessary complexity. Mm-Hmm. where the design has not evolved along with the understanding of the problem. There is an opportunity to remove some unnecessary complexity. Right, right. Uh, very narrow. But that, I mean, you're absolutely right to hit on the, the fact that that complexity period is compounding. Right. Here's a thought experiment for you. Let's say that you have a, uh, well, have we done, have we done the Alice and Bob and going to the park? Have we talked, I'm just gonna say this again, forgive me for dearly
Matt Godbolt: If, if this a repeat doesn't ring a bell for me, but that doesn't mean anything. I'm still mildly hungover. As you may have picked up
Ben Rady: Yeah. Right there with you. Um, so you have, let's say that you, you accidentally give, uh, you know, two programmers on a team the same problem on the same day, right. Uh, Alice, Bob, and, uh, you know,
Matt Godbolt: They're not sending cryptic messages to each other and
Ben Rady: Not, in this particular example
Matt Godbolt: And no one is trying to intercept it or whatever. But they're two regular programmers on the team
Ben Rady: They're just two programmers trying to solve a problem. And they accidentally are both trying to solve the same problem at the same time, not knowing that the other person is working on it. And so Bob sits down and he writes a thousand lines of code to solve this problem. And this code is perfectly designed. It is as simple as it could possibly be. Mm-Hmm. , it is well tested. It is well designed, uh, it is correctly documented. So whatever level of documentation is appropriate for this project Right. Is apply that level of documentation, . Um, and it solves the problem perfectly. And he spends all day on, on working that at the end of the day, he, you know, pushes his changes into a PR and sends the PR to Alice saying like, Hey, can you please review this? And then meanwhile, Alice, meanwhile, while all this is going on, Alice goes to the park and she sits in the park and she feeds the pigeons and she thinks about the problem. And she sits there all day feeding the pigeons and thinking about the problem. And she comes back to the office at like four 30 and she deletes three lines of code and pushes a pr fixing the same problem that Bob fixed . Which of those two, two solutions is better?
Matt Godbolt: I mean, the one that involves sitting in the park is better, just, you know. Yeah.
Ben Rady: Obviously Alice's solution is better, right? Yeah. Yeah. There's no unnecessary complexity in Bob's solution. None other than the fact that he just wasn't really solving the right problem. He didn't understand that the way to fix this is to just not do these three things. Yeah. Yeah. Instead of accounting for, and
Matt Godbolt: I think we can all think of things that fall into that, that kind of category of like, you know, this is a perfect solution to, so he, you know, for example, we just talked about this, like the cache that I'm talking about here is a big cache for these giant files that I download from wherever, whatever. And the three line fix really, if I had the access to the code that I needed, would be just read the files directly from the network appliance, don't download them to the cache, and then manage to manage your cash. And so, like here, I'm, I'm adding, adding complexity here to deal with Mm-Hmm. the, the problem that I've created myself. Whereas if somebody was smarter than me and could work out how to get the, the just, yeah. You, you, you're with me, you're with me on this.
Matt Godbolt: Mm-Hmm. . And, and yeah. It's, I like to think of this as the, uh, the old lady who swallowed a fly, you know, the children's rhyme. Yeah. And, you know, she swallowed a fly, perhaps she'll die, and then she swallows a spider to catch the fly. And we're all, we've all written spider level fixes for something. Mm-Hmm. . Right. You know, like there's this thing, I don't think about it, uh, but I can solve it by, by swallowing a spider. And then, you know, the, the, the, the tail continues until she's swallowing a horse. And I think at that point, you really, you should be fired actually, if you're considering swallowing a, a horse . But, you know, it takes, it, there's a lot of inertia because there's a lot of code that's written in the horse, the cow, the dog, the cat, I'm trying to remember now. the cat, the frog, the spider, I don't know, whatever it was that she swallowed to swallow the fly. And then what you really wanna do is go back and say, back in time as we can as developers and say, let's just not swallow the fly in the first place. Right. And now we're good . Right. And that's Alice there.
Ben Rady: Or, you know, and, and getting back to my sort of Alice Bob, uh, hypothetical scenario, one way that that could very practically play out is what Alice was thinking about in the park is, is it really bad if we swallow a fly? Because maybe we could avoid this whole thing by just taking on a very small risk that is a completely acceptable risk Yeah. And is totally better than a another thousand lines of code.
Matt Godbolt: Yeah.
Ben Rady: So I'm just gonna go delete these three lines, and there's a chance we'll swallow a fly. And turns out that's just a little bit extra protein and we'll be fine.
Matt Godbolt: Yeah. Maybe that's, yeah. So that's an even better analogy. Dead. And there's Yeah. There's sometimes it doesn't Yeah, I'm with you. Yeah. Just deal with it. You swallow the fly. All right. Yeah.
Matt Godbolt: Restart the servers once every three months or whatever's rather than the Yeah. Well, we've got this thing that's follows this, you know, that you've seen like this, um, sipping bird, you know, those sipping bird things that Mm-Hmm. like, you, you kind of heat up and then they kind of like keep dipping forward. There was, I i, if, I think it was a Google a whole thing with that, which was like, the thing at the very end of the chain that kind of like, um, causes everything to continue running is the sipping bird that's hitting like the space bar on the computer console. That's like, yeah, yeah, yeah. Carry on. Whatever. It doesn't matter. Just, you know, somewhere along the line of complexity, this Rube Goldberg machine that you've built, you're like, something has to be physically at the server pressing the button .
Matt Godbolt: Yeah. And you could, you could do worse than a little sipping bird now that we've gone all over the place with that, but Yeah. Yeah. That's a really powerful thought. Is that like the, the, the fact that you could be trading a very small risk for a ton of complexity Mm-Hmm. and say, I'm taking on this very small risk and I'm fine with it, actually. Yeah. It's all right. Yeah. You know what? I'm not gonna worry about what happens if you run outta disc space, um, and all the cleanup code that might go with it. I'm just like, well, if it happens, we'll get paged. That's fine. Or the, that particular process will die. The machine will get recycled, the new one will come up, and we'll go and look for why that happened. But we don't have to have proactive, like cash, whatever, you know, just again, top of mind for me. So I'm gonna keep drawing on whatever I've been doing the last couple of hours. No, that's really interesting. Yeah.
Ben Rady: Yeah. And I mean, the other thing that you can do with this, we were talking about trading off, like how do you get rid of complexity, right? This is the thing that feeds on itself. This is the thing that makes it harder and harder to add stuff. Yes. We want to eliminate accidental complexity. What a lot of people would say is technical debt, what Ward was talking about with that very narrow definition there. Okay, yes, we wanna get rid of that, but sometimes the only way to make this better is to get rid of essential complexity. And that's by changing the problem. Hmm. Everyone has seen, like the Kanban board or the task board, or the Jira, whatever. Here's all the 75 things that we need to do. Right. What percentage of those things are remove this feature?
Matt Godbolt: Yeah. That's never a,
Ben Rady: It's never on that board,
Matt Godbolt: Is it? Very rarely. Very,
Ben Rady: Very, very rarely.
Matt Godbolt: I have one right now, but it's mostly a, i, we migrated a system and then we should get rid of the, the old system. And you know how long that has been kicked down the can about one, you know, three months now. Yeah. I'm like, eh, it's not, still not really important enough to get rid of even though Yes. Yeah.
Ben Rady: Yes. Or that's just what you preached. Or maybe even more so here are all the features that are not carrying their complexity wake, wait, they're useful, they're valuable to somebody. But we've decided that, you know what the 10,000 lines of code that we have in our system that supports this one feature Yeah. That is not worth it, is going to be removed. And there's been the, you know, conversation with the group or the person, whoever it is that likes this thing. It's like, I'm sorry, I know you like this. Here's this alternative that we wrote for you in 12 lines of bash, ,
Matt Godbolt: .
Ben Rady: Right. It's not as good, but it does the job, but
Matt Godbolt: It does the job. And more
Ben Rady: Importantly, it'll save, save us this giant chunk of complexity
Ben Rady: That, I mean, you know, a not totally off way to think about these kinds of things in terms of managing complexity is, again, regardless of whether it's accidental or essential or whatever, is, imagine if every time you wanted to add the line of code to your system, you had to read log-based 10, uh, of the lines in your system. Right. . Mm-Hmm. . Mm-Hmm. . So you can, you can very easily and quickly see how you're gonna get slower and slower and slower and slower the more stuff that you add. Yeah. Yeah. And so thinking about how you're going to manage that complexity and thinking about what tools you have in your arsenal for getting rid of it, obviously getting rid of actionable complexity. Great. If you find it, get rid of it, you find code that you don't need anymore deleted, you find things that are too complicated can be simplified, great. Do that. But you have more tools than that. Right. And you need to use them, because if you don't, what will eventually happen is your system will turn into a haunted graveyard. Uh, it will turn into the thing that everyone is scared to touch. Like, oh, don't go there. Every time you make a change to that thing, it breaks. 'cause nobody understands how it works anymore.
Matt Godbolt: Right. Right, right, right,
Ben Rady: Right. And then people are like, well, we just need to rewrite it. Right. And then you rewrite it, and then the cycle begins anew,
Matt Godbolt: ,
Ben Rady: And you have a whole
Matt Godbolt: Phoenix from the ashes of the previous system with all the same flaws.
Ben Rady: Right: How dear listener, how many times have you seen in your career the phenomena of the old system that has turned into the haunted graveyard that nobody wants to touch, and then they bring in a new person to maintain it, or maybe a whole two team, and they look at it for a few months and they're like, the solution here is a rewrite, we're going to rebuild it. Yeah. And then they rebuild it, and then five years later, the exact same thing has occurred. I can see,
Matt Godbolt: Right? Yeah. Yeah. We, we, we actually, we turned it around, uh, . So, uh, one of the things that I've seen happen a number of times is that if you've got a, facility that is sort of not exactly required, you know, maybe it's a visualization tool or a monitoring tool, or in, in our case, a simulator for something, then, uh, that's when the, you know, junior folks come in and you say, Hey, we're gonna rewrite it again. Um, and you get to do it as a way of learning how we do software development here, or we're gonna write it in a new language that we're just trying out here. And if it, you know, we know that we're gonna rewrite it again in another year's time, because we always do. So, at least in that way, you're kind of capitalizing on the idea that this this thing is essentially permanently cursed ,
Ben Rady: Right? Yes.
Matt Godbolt: It is. Just, it's, it is, it's a haunted house on purpose. Right. You know? Yeah. It's like
Ben Rady: The Halloween haunted house where you go there. It's just a fun time.
Matt Godbolt: Oh, it's meant to be like this. I see. Okay. Right. You know, we wr we wrote it in, you know, Scarla, have you got anything else written in Scarlet? No. It was just seemed like a fun thing to do and you were gonna rewrite it again anyway, so, gosh,
Ben Rady: That, that is scary.
Matt Godbolt: , let's not offend anyone who, who . But, uh, but yeah, no, it's true. That, that, that certainly, um, larger code bases in particular suffer from this or larger area. Mm-Hmm. You know, areas, especially when, you know, you mentioned something about like, Hey, this, is this code even used or is it used by one thing once or is there a test? You know, we've all seen code bases that grow and grow and grow, and nobody has cu out the stuff that isn't used. And if you're not careful, you find that if, if you're very lucky, you find the only use is the test that tests the functionality. And then you ask yourself, well, it apparently is used, but it's used by a test. Right. Does anyone other than the test use it? No. Do we really need it? Um, because it's, it is a bit of a millstone now with all the automatic refactoring tools that we've got, it's a little bit easier to carry around unused code a little bit easier. But in, in the old days, should we say, of like grips and finds and replaces, the more chances of hitting things that you don't need, um, the, sorry, the, the more, um, the larger your code base with unnecessary mentions of things that may or may sound like the thing that you're trying to change, the more likely you are to get like, collateral damage of hitting, you know, your regex hits, renames the wrong variable or whatever. Or you forget to update one case of it or any things like that. Yeah.
Ben Rady: I mean, I think even with the refactoring tools, there's a cost there because the tree of dependencies, uh, isn't shaped the way that you want. If you've got some piece of code that's unused, so nothing calls it. Right. It can still call lots of other things. Yeah.
Matt Godbolt: That's, and
Ben Rady: That's by doing so it puts a constraint on what those things can be.
Matt Godbolt: Yeah. Okay. That's fair. Right?
Ben Rady: Yeah. I mean, how many times have you had this thing where you're sort of like, wow, I really wanna change this return type, but I, if I do, it's gonna screw. So what do you, what calls that? What calls that? What call Nothing. Nothing calls this , this whole chain is why have I spent the last half an hour look at this code? Right. I could have just changed it as soon as I saw it. Right? Yeah, that's true. Um, so yeah. That you, that that unused code, and I mean, you know, you say it's sort of like, you know, do we need to keep it? It's like, well, you've, you've already kept it. If you're looking at it, there's a very good chance it's in your source control and
Matt Godbolt: It's, and then you can go and get it. But so
Ben Rady: Actually quite difficult to remove from the source control. So ,
Matt Godbolt: But, but, but then, you know, uh, the counter to that, and this is a weak counter, I think just thinking out loud, really, um, the counter to that is that if it is in source control, it is stagnant. That's true. If you come back to it like three months later and go, didn't we have a thing that did the, the other stuff? And then you find that it doesn't work anymore, but then what you're trading off is the cost of the, of the incrementally keeping a piece of code up to date and the transitive closure of things that use it or have been used by it. Right. That maybe is like a null set or maybe is a large set of things, but they're just inconsequential and they actually hurt you. Right. Yeah. That's one cost against the speculative cost of if we were to remove it and then have to resurrect it, talking of haunted graveyards.
Matt Godbolt: Mm-Hmm. again, right? Yeah. If you do need to resurrect, uh, this, this, uh, piece of code and functionality, you might have to do a little bit of surgery there. And then, and that seems often like, that might not be as bad as it sounds. Now, obviously if everything's changed under your feet, it's no longer a li you know, version seven of its library is now version 94 and the whole API is gone and you dunno what you're doing with it anymore, but maybe, yeah, it's very subjective. I guess it depends on the, but like yeah. Again, this is a risk or a trade off that we talking about the beginning of this. Like what's the risk if I take this out, there is a risk that we may need it in future. And you could actually say, I'm removing this capability Mm-Hmm.
Ben Rady: Right.
Matt Godbolt: And trading off for the risk that we might need it again in some indeterminate amount of time and maybe I can wear that risk. Mm-Hmm. . And in doing so, I have removed some essential complexity because it's essential because it supports a capability that we say that we needed. Yeah. But I'm trading off a risk. Yeah, that's,
Ben Rady: And I think there's another bet that you're making there when you keep that code because you think you might need it one day, which is your option, is delete it and recover it from source control at some point in the future when you decide you need it again. Mm-Hmm. or keep it and pay the cost to maintain it through all the transitions of all the other code between now and then, right? Yep. It is entirely possible that the work to reincorporate it in the future will be smaller than each individual change that you have
Matt Godbolt: To make the integral of the area under the graph.
Ben Rady: Right. You might change it one way and then change it back the other way. Yeah. And then change it one way and then change it back the other way. And if you could just hop from the beginning to the end, it would actually be way cheaper. Right? Yeah. And it's hard to say. And so like, you know, for me personally, if there's code in the code base that isn't used unless I like, no, like I'm working on this next week, I'm going to add this capability in next tomorrow, the day after, right? Like it's, it's gonna be there, like it, it's the next thing in my list. You know what I mean? Yeah.
Matt Godbolt: Right. Right. So
Ben Rady: Unless it's something like that, I'm gonna delete it every time because I know it's in source control, I'll know it'll bring it back. There's a very good chance that when I bring it back, it'll actually be easier to reintegrate. Mm-Hmm. . And if nothing else, I can sort of reevaluate the capability in the context of the new design, right? Like I can be like, okay, this is the capability I want. Here's some code that does it actually now I only want these like eight lines. Okay. And I'm gonna put them over here bit instead of where they were before.
Matt Godbolt: A step back from, from it, a little chance to reevaluate it in, in the light of new evidence instead of the incremental, like, well, I'm just keeping the test passing aspect of it that maybe you were doing before, which is not as thoughtful as, uh, as, sorry, intentional, you know, as, as the Okay now I, I've, I've got it in front of me and I can make it fit the design as it sees as it is now, as, as it has evolved in one step rather than the thousands of paper cuts along the way.
Ben Rady: Yeah, yeah. Exactly. Exactly. So, I don't know, but this is, this is kind of my, my, my proposed replacement for technical debt. And this is, again, when you're talking from, when you're talking to programmers, when programmers are talking to programmers, they don't need to use metaphors. If you wanna keep using technical debt with your boss, 'cause he knows what it means, and you know what it means, and you have a common understanding of what it means, that's fine. I'm not telling you not to do that. But if we're talking about code, we can be more precise. We can talk about risks, we can talk, talk about capabilities, functionality, we wanna call it, we can talk about complexity. I think every programmer, uh, suffers at that. Right. Suffers from that. Yeah. Um, and we can talk about the trade-offs between those things. Yeah. Right. Because sometimes those trade-offs really make sense to make
Matt Godbolt: Yeah, no, no, it makes a lot of sense to me. I was just about to make an argument for one of the few places where I see complexity budgets being spent in places where you wouldn't expect them to be, but it's still essential complexity is in high performance code. But I think that's just a capability, you know, the, the, the capability of like processing something in a certain amount of time. You know, I I, I was gonna say, but performance is another category, but no, I think we can quite, quite reasonably call it a capability, you know, or like a a a sort of constraint, a design constraint on the system. Mm-Hmm. it must be able to do X and you can say it must be able to do X in Y or with latency lower than whatever. Um, you know, we've all seen those bits of code, right?
Matt Godbolt: You know, the, the beautiful, the beautiful, uh, you know, design where you've got every little object that has its own little responsibility, and then ultimately you go down and say, no, it just needs to be super quick. I'm just gonna sit down and write the very complicated thing with all, with this more comment than it is code, because I'm explaining why we're not calling this whatever, and we're resum. Yeah. And then you're like, this is costly. And the far extreme of that, actually, I was giving a, um, a chat at lunchtime, uh, couple of weeks ago, and I was walking through some of my 90 late nineties era Dreamcast code, which includes some Hitachi SH four assembly code as well. And it's like, you know, you've seen my code, you know, that I tend not to, um, I tend not to, uh, comment that much.
Matt Godbolt: I, I rely on like useful variable names and function names and extracting, but like when you're writing assembly, you've kind of got no choice. And so it was just a wash with this prose about what I'm doing, how it's doing, why this allocation's like this, why the format's, like whatever. And everyone's gonna like, why is it so well commented? And I'm like, well, 'cause it's so complicated. And then I said, the problem with this though is that like, if someone turns around to me and says, can you make it do X? I'd be like, no, I can't. Yeah. Right. It's, you know, this is a huge deal now and it's hard to change. And that's the complexity. Anyway, that's the complete aside. I guess I, you know, we've looking at the time, we should probably, uh, I think we've reached a natural conclusion here. I think think you've, I think you've said what you needed to say about this, which is that like technical debt is probably not what you think it is unless you're Ward Cunningham or Ben Rady , and now maybe anyone who's listened to, to this, this podcast. Yeah. Maybe it's excusable to colloquially refer to kind of any naf bit of the code base for whatever reason as technical debts to Mm-Hmm. , non-technical folks. Yeah. Um, but it's probably, no, it's not probably, it is definitely more useful to describe it in a more specific term and your, your, uh, when you're talking to other programmers and it's either a, a risk, a capability or a complexity, and those are the things that, that you, that you are knowingly trading between and the Yeah, that makes sense. Mm-Hmm. I like,
Ben Rady: And this is, this is what I'm aspiring to do. I mean, I still use the term technical debt. Like it's, it's, it's something where it's like I catch myself and I'm like, can you be more precise about this? Ben, can you, can you describe what you're trying to say better?
Matt Godbolt: Is this when you have your one-on-ones with yourself
Ben Rady: In the shower
Matt Godbolt: Yeah. That is where, that is the place where most of the, the real deep thinking happens, isn't it? It's like you are just the right side of, of, of wakefulness, but not yet fully booted up. Right. When you've not had the coffee or anything like that, Uhhuh and you are, you've got no other distractions and Yeah. It's like a meditation, isn't it? That's when you really, these things come out. Mm-Hmm.
Ben Rady: Or sitting in the park next to Alice.
Matt Godbolt: All right. Yeah. Feeding the ducks with Alice. Alright, that sounds like a perfect place for us to finish. Yeah.
Ben Rady: Cool.
Matt Godbolt: See you next time. Bye.