Matt Godbolt: Hey, Ben.
Ben Rady: Hey Matt.
Matt Godbolt: Well, how on earth are you, my friend?
Ben Rady: I'm good.
Matt Godbolt: And we were we were just we were just chatting.
Ben Rady: I'm good.
Matt Godbolt: And and actually, I'm gonna stop you right there. And I think you're clipping. I'm just looking at your stream. Do you mind turning the gain down on your microphone a tiny bit?
Ben Rady: Oh, really? I'll do my best. Hold on.
Matt Godbolt: Yeah, thing on the back. I think you've turned it up.
Ben Rady: I don't know if I just turned it up or down. I think I just turned it up.
Matt Godbolt: Yeah, try the other way.
Ben Rady: Okay, how about that?
Matt Godbolt: Yeah, keep going.
Ben Rady: This? No? No, that seems more gain.
Matt Godbolt: No, that's worse.
Ben Rady: I'm going to go this way.
Matt Godbolt: That's better. that That seems good.
Ben Rady: Yeah.
Matt Godbolt: That seems good. Okay, hey, right.
Ben Rady: All right.
Matt Godbolt: Now, Likely as not that will actually make it into the edit because I'm too lazy to take it out. So, uh, anyway, hi, we were, we were just talking as we are, as we were planning in the sort of 35 seconds before I just said, Oh, I'll just hit record.
Ben Rady: Yes.
Matt Godbolt: And you said you had an idea for a talk and then you gave me the option of talking about it ahead of time, which would be sensible or going into it cold. And I'm like, eh, let's just do it.
Matt Godbolt: And then I hit record.
Ben Rady: Uh huh.
Matt Godbolt: So tell me about your idea for a topic.
Ben Rady: So this is a this is a follow up to a prior episode, the prior episode on technical debt.
Matt Godbolt: Okay. Yeah.
Ben Rady: Um, and so in that episode, if I remember some of it partially, I had some like somewhat formed ideas about alternatives to ways of thinking of technical debt.
Ben Rady: And I think I was very clear in that podcast, like this is so, this is new material.
Matt Godbolt: Right.
Ben Rady: These are like new ideas that I'm trying to smush around form into something reasonable.
Matt Godbolt: right
Ben Rady: and ah not to recall the pain of our iterative versus incremental podcast, but um I have a new iteration on those ideas.
Matt Godbolt: Oh, no.
Ben Rady: And I actually, ah it's it's an it's an iterative improvement.
Matt Godbolt: Is it an incremental improvement, would you say?
Matt Godbolt: Okay, all right.
Ben Rady: Yes.
Ben Rady: So you're doing it.
Matt Godbolt: I'm doing it.
Ben Rady: don't and Those are the worst names.
Matt Godbolt: You made me do it. You made me.
Ben Rady: And actually this ties into the other thing.
Matt Godbolt: Oh, all right.
Ben Rady: um Those are the worst names.
Ben Rady: And names are important. Names are very important.
Matt Godbolt: Yeah, they give things power sometimes.
Ben Rady: ah Names, if you're if you're a regular listener of this podcast and you heard us talk about patterns thinking and how patterns thinking is an important part of learning new skills, learning to think in patterns and giving those patterns names.
Ben Rady: If the patterns don't have good names, no one will remember them.
Matt Godbolt: Right.
Ben Rady: And it sort of defeats the purpose, well, not the entire purpose, but a lot of the value of the of the patterns.
Matt Godbolt: No, but it's, I mean, let's just in in terms of in terms of the gang of four patterns book, you know, part of the the thing that gave that the power is the fact that now we have a new language we can use, and I say a singleton, and you know what I mean, or I say a flyweight, and you know what I mean, and we and it carries a lot of baggage with it.
Ben Rady: Mm-hmm.
Ben Rady: Exactly.
Matt Godbolt: And, and without the name being both attached to the concept and being memorable and sort of concise, it doesn't have as much sticking power or wouldn't be as important, right?
Ben Rady: Exactly right. And that's the problem with iterative versus incremental because they both start with I and no one can remember what they mean. But there's another name that we have that ah we use a lot in software and it doesn't really have a single meaning and that is technical debt. And we talked about that a little bit in the prior episode.
Matt Godbolt: Right. Although you know you I think you made a reasonable argument that there is a single meaning for it and then everyone has used it wrong ever since.
Ben Rady: Yes.
Matt Godbolt: But then de facto and de jure are two different things.
Ben Rady: Right.
Matt Godbolt: And de facto, when we say technical debt, we just mean bad programming things that we'll go back and fix later, sort of.
Ben Rady: Sort of, exactly. So yeah, so the original definition that war came up with is no longer the definition that people use, they sort of make up their own.
Matt Godbolt: Mm-hmm.
Ben Rady: And therefore, it's lost a lot of value as a thing that we can use as a pattern to talk about, unlike the singleton or the flyweight or the decorator or any of those gang of four patterns, where it's like, people, I think generally agree on what those mean.
Ben Rady: I literally yesterday asked a whole room full of software engineers, what does technical debt mean to you? And I got 10 different answers, right? And they were all sort of related
Matt Godbolt: Right. Only six people in the room.
Ben Rady: Yeah, actually, that's 100% correct. um And so you know it's it doesn't have as much value.
Matt Godbolt: Right.
Ben Rady: And so part of that original podcast was, OK, maybe we can find a way to make this a little bit more useful. And I've given this a lot of thought. And I i now know that I've come up with an and an improved version of this because it has a catchy acronym
Matt Godbolt: Oh. Okay. Forgive my lack of enthusiasm. Go ahead.
Ben Rady: That was that was the best response in this entire podcast.
Matt Godbolt: What is your new acronym? well What?
Ben Rady: I guess we're going to talk about this for the next 30 minutes.
Matt Godbolt: I mean, you've come up with some good ones. I'm not going to dispute. There are some ones, but, you know, I know about like, you know, your FIRE acronym, but unfortunately I can probably only remember what one or two of the letters stand for now.
Ben Rady: yeah Yes. Yes.
Matt Godbolt: Now I'm just put myself on the spot.
Ben Rady: Mm, it's probably.
Matt Godbolt: Fast, something repeatable.
Ben Rady: Uh huh.
Matt Godbolt: ah Yeah. what what does Remind me: FIRE.
Ben Rady: Fast, Informative, Reliable, and Exhaustive.
Matt Godbolt: Oh, okay. See, I got one.
Ben Rady: Yeah.
Matt Godbolt: One out of four is not as bad.
Ben Rady: You got one. Well, you got the most important one, which is Fast.
Matt Godbolt: ah Okay, fast. Anyway, all right, so tell me what your acronym is...everyone ready?
Ben Rady: All right. The handy acronym is CRUFT.
Matt Godbolt: Oh man, that's a good one.
Ben Rady: Isn't it though? Isn't it though?
Matt Godbolt: Okay.
Ben Rady: And the and so CRUFT stands for Complexity, which we've definitely talked about a lot, Risk, which we've talked about a lot, Uses or Use cases, depending on exactly how you want to frame it...
Matt Godbolt: Oh, ah sense a sense of weakness in the force.
Ben Rady: But basically, like the useful the useful accent aspects of your software, which are arguably the most important part. right It's the thing that you know hopefully hopefully, if you're doing it right, is making use of money, but not necessarily.
Ben Rady: ...Feedback, which is an essential part of any software development process.
Matt Godbolt: Okay. Yeah.
Ben Rady: And Team, specifically team size. And that relates to bus factor. And I can talk about all those kinds of things.
Matt Godbolt: Okay.
Ben Rady: And so my hypothesis here is that when you're talking about technical debt, what you're probably doing, and I think this is actually true of most senior software engineers, and they just, unlike me, who you know they don't spend the time to like build systems out of the way that they think because they're not trying to teach them to other people.
Ben Rady: It's like, Ben, why did you do that? It's like, I don't know. It just seemed like a good idea. It's like, no, I need a better answer than that, right?
Matt Godbolt: Yeah, yeah. yeah
Ben Rady: It's like, I don't know. I can't really explain it to you. So because I'm in this situation where I'm forced to explain my thinking to other people, ah I think that there are lots of situations in which senior engineers are making decisions along these dimensions and not even realizing that that's what they're doing.
Ben Rady: They just sort of do it out of their experience, right?
Matt Godbolt: Yeah, yeah.
Ben Rady: um And so I kind of think of this, if you wanted to share this thinking, as as a five-dimensional portfolio optimization. You've got these five dimensions.
Matt Godbolt: on brand for, for day job. Yeah. yep yeah Right.
Ben Rady: Exactly, exactly right. um And it was not lost on me. so Somebody, when I was explaining this, mentioned to me, it's like, okay, so your problem with technical debt is it's a financial metaphor for financial people, and then you replaced it with another financial metaphor.
Ben Rady: It's like, okay, yeah, that's good observation.
Matt Godbolt: Astute observation. Yeah.
Ben Rady: Portfolio optimization is not strictly financial and also hopefully not very metaphoric, right?
Matt Godbolt: Yeah.
Ben Rady: There's no interest rate of technical debt. you know, despite how many times people want to draw that, there's no, that's not a real thing. That's a pretend thing. It's not a real thing.
Ben Rady: um But I think that these dimensions are real in the sense that they are quantifiable. And um I think I can explain how you could quantify every one of them.
Matt Godbolt: Interesting. Okay, the U I'd be interested in because that would seem to the weakestly defined thing. But yeah, I get the complexity can be somewhat defined as any number of are both algorithmic, you know, complexity, but also just lines of code is not a bad proxy for complexity, or number of systems or libraries or dependencies or something like that.
Ben Rady: Exactly.
Matt Godbolt: So yeah, get I get that um risk. Yeah, how do we define risk? How can you numerically define it, quantitatively?
Ben Rady: So if you really wanted to stand on the shoulders of giants, there are many people who have tried to quantify software risk in the past. And I think a lot of those techniques are very effective if you want to apply them rigorously.
Ben Rady: If you want a very rough estimation of this, just look at the incident issues in your backlog or the, you know, the error incidents in your backlog or whatever it might be.
Matt Godbolt: Right, right.
Ben Rady: And maybe you have a different category for things that are speculative risks, right? Like like this, yeah.
Matt Godbolt: Right. That's what I'm used to doing. Yeah. It's not the idea of like, you know, you you write down the risk of like, what would happen if, and you come up with a few of the things that are really important and you go, well, how do I offset those? And the more of those you can think of, like, well, what if this happens? What if that have we accounted for this? What if the business changes direction, whatever, those kinds of things could be seen as risks. But yeah, I get it. Yeah. GitHub issues is not a bad proxy for it. At least in some mechanism um of, you know, anything, any outstanding known issue that you have is definitionally a risk. It's like, Hey,
Ben Rady: Right.
Matt Godbolt: If two people try to do this at the same time, then we get an exception thrown and then we, somebody has to deal with this out at customer services. That is a risk that we're, and we're riding that risk and yeah, got it.
Matt Godbolt: yeah Okay. So we'll see our, and this is an easy acronym to remember at least and very, very apt.
Ben Rady: It's a good one. So like the the Risks are like unwanted behavior in your software.
Matt Godbolt: yes. Yeah.
Ben Rady: The Uses are wanted behavior. Like if you want a really simple way to think about it, right?
Matt Godbolt: Oh, that is interesting. Yeah. Okay. So uses here in this instance is like, yeah, functionality that people are happy with or are happy enough with that's providing value to someone somewhere. As you say, maybe it's making the company money. Maybe it's like the raise and debt for a few open source so project, whatever it is. And that that is one of the things that has kind of a, ah it'll have in the optimization problem, it should have a negative weight risk with respect to complexity and risk, we hope it should have the opposite sense to that because obviously, you want to optimize for the highest uses and the lowest risk, presumably amongst all these things or the things.
Ben Rady: So I would actually argue that really what you want there is a high correlation between the uses that you have and the uses that you think will make you money.
Matt Godbolt: Yep.
Ben Rady: So more uses are not strictly better
Matt Godbolt: Okay, yeah, yeah.
Ben Rady: Even, and and this and this is this is where it's like, the applying this practically, I think you're going to wind up with the constraints where it's really not possible to, or it's very unlikely that you're going to be able to increase the uses without increases increasing complexity or risk or some other factor that's bad.
Matt Godbolt: Right, but then that's, you know, required complexity versus unnecessary complexity we've talked about before is, to some extent, you know, that is necessary.
Ben Rady: Right.
Matt Godbolt: So if we want to get something done, then it takes a bit of, yeah, okay, yeah.
Ben Rady: Right. But I would argue that there's probably a sort of equilibrium with uses. It's not that you're trying to maximize it or minimize it. you're You're trying to hit the right amount for the things that you understand will be valuable.
Matt Godbolt: Yeah, that makes sense.
Ben Rady: Right. Now, practically, on most software projects, there's a never-ending list of things that people think might be valuable. And so you're never you're never really going to like like, all right, we've added all the functionality or software that we ever need to add.
Matt Godbolt: Tell me about it.
Ben Rady: We're done. Like, that never happens, right?
Matt Godbolt: Yeah. Yeah.
Ben Rady: um But I think the the important thing to understand about that is it is entirely possible that there are uses in your system that you want to remove. And I think that this model gets very interesting when you start thinking about the trade-offs between them, right?
Matt Godbolt: Right.
Ben Rady: So you're like, I'm going to reduce risk by removing uses.
Ben Rady: right Like here's a use case that we don't want to support anymore because it has a lot of risk associated with it.
Matt Godbolt: yeah.
Ben Rady: right There's cases that we don't handle, there's edge cases that we don't handle, and we could handle those edge cases and that would cost more complexity. But another way to handle this is just remove the use case.
Matt Godbolt: Yeah, absolutely. And I mean, we don't do that often enough, I think is is probably the point that you're sort of getting at here, or at least, you know, without it being, you know, there in front of you in in numbers, you know, want one way to change our objective function that says, you know, we wish we we we do want to maximize, which is some kind of relation, as you say, a ratio of these things is to say, well, let's just get rid of the thing that doesn't really work that people don't really use.
Ben Rady: Mm-hmm.
Matt Godbolt: Or when they do, they always hit this edge case. Let's just say we don't do that anymore.
Ben Rady: Yeah. Yeah.
Matt Godbolt: It's fine. Yeah, okay.
Ben Rady: Yep.
Matt Godbolt: All right. i've You've sold me on the U now.
Ben Rady: Okay.
Matt Godbolt: I like it. I and it's not the inverse of either C or R. And in fairness as well, while there are sort of correlations between these things, they're not all totally orthogonal axes. Are they, um you know, like complexity and risk sort of go hand in hand.
Matt Godbolt: I mean, like some of the risk is the fact that something is complex.
Ben Rady: Yep. Yep.
Matt Godbolt: um but But they are.
Ben Rady: Yep. Like any portfolio optimization, you're gonna wind up with situations where there there are relationships between the the dimensions, right?
Matt Godbolt: Yes.
Ben Rady: You increase one and you decrease or increase another one, and it's sort of like there's, in some cases, no way around that, right?
Matt Godbolt: Right. Right. You know, you buy, you buy Apple shares and you've got more tech sector risk and that's, that's okay.
Ben Rady: Mm-hmm.
Matt Godbolt: Sometimes they are maybe different or whatever. There's some, yeah, some, something, something portfolio optimization problem here risk. So that's actually interesting because and maybe we should pause here on the U, but like one of the things that we do in our day jobs is that we have ways of taking the many things that we have and and applying a risk model to it, which obviously is different from the risk we're talking about are here.
Ben Rady: Mhm.
Matt Godbolt: It's like, which is essentially the objective function is a thing you want to minimize um ah or at least take into account when you're trying to maximize something else. You know, in ah in the case of what we do in our day job, it is maximizing the amount of money you make while reducing the risk that that requires to go forward the risk.
Matt Godbolt: And that's, ah that's kind of some weighted sum of all of those things. um And so yeah, here, that's what you're talking about with the ratio of like, well, okay, we we increase the uses, but it also increases the risk and the complexity, maybe those net out, and we don't actually, that's not actually better.
Ben Rady: Right, exactly right.
Matt Godbolt: yeah Yeah, yeah, okay. All right, sorry. And then you've got to something else to say on that, or or we're ready to go to the F, which I am about to try and remember, I'm definitely a normal human who can remember things for more than 14 minutes.
Ben Rady: Yeah.
Matt Godbolt: ah No, tell me what the F was.
Ben Rady: Feedback.
Matt Godbolt: Feedback. Okay.
Ben Rady: Yeah.
Matt Godbolt: All right.
Ben Rady: So how do you know if your uses are valuable? I think that's like the most important form of feedback. It's like, did the software that we build actually make any money? And in trading that's easier to do than in a lot of different contexts, which is, you know, you put the strategy into production, you see if it makes any money, but there's lots and lots and lots of other situations in which you need to create feedback loops to write.
Matt Godbolt: Are my users happy with the way that the thing's going? Are, yeah, is, is you know, in my website.
Ben Rady: Is my software using the amount of memory that I expected it to use, right?
Matt Godbolt: Oh yeah.
Ben Rady: you know um If I made a change to my software, did I break anything?
Matt Godbolt: Yeah.
Ben Rady: That's an obvious one that's on brand for us. That's a feedback loop.
Matt Godbolt: Have we increased or decreased the performance? Let's just get both sides of this.
Ben Rady: Exactly, exactly, exactly right.
Matt Godbolt: Can I measure it and see? Yeah. Okay.
Ben Rady: Yes, yes, yes.
Matt Godbolt: So that's, that's, yeah.
Ben Rady: And so the way in which you, oh, I guess one step back to you for just a second.
Matt Godbolt: Yeah. Yes, sir.
Ben Rady: I made the claim that all of these are quantifiable, and I would say easily quantifiable.
Matt Godbolt: Yeah, yeah.
Ben Rady: I think the easiest way, the sort of like you know the if complexity is just like roughly the number of lines of code, which I think is actually a pretty good estimation of complexity, the pretty good estimation for uses is the number of passing tests.
Matt Godbolt: That is interesting. Well, that is true. Okay. I will, but but I'll take you back on that because one of the things that you were saying is, you know, like things that people want that are used to evaluate generating business value, because I can sit down and write a thousand tests for a piece of code that nobody actually needs or wants.
Ben Rady: like Those are the things that you know your software can do.
Ben Rady: No, no, I'm specifically saying that uses are not necessarily valuable.
Matt Godbolt: And that's Oh, I see. sorry Yeah. Yeah. So actually to back that up specifically. Okay. Got it.
Ben Rady: Yeah, yeah, yeah. Like their their behavior of your software, are they valuable? I don't know. If they're not valuable, then we should remove those uses because it probably removes complexity and risk, right?
Matt Godbolt: Yeah.
Ben Rady: But yeah, the uses are just, these are the things your software can do. Whether they're valuable or not, maybe the feedback will tell you, right?
Matt Godbolt: I see. Yeah. Yeah. Okay. And then it's a so slightly weaker coupling than something you can directly measure, but it's part of that whole.
Ben Rady: Mm-hmm.
Matt Godbolt: So yeah. So feedback can be a user satisfaction. It can be performance. It can be, um, test coverage. It can be, uh, times CI build times.
Ben Rady: Test time, CI build time. Yeah.
Matt Godbolt: Uh, it's just anything you can measure objectively about your code. Um, what about things, you know, like. you know, ah log incidents, I mean, you kind of alluded to this with the R thing here, but you know, like, you know, the number of warnings that you're logging out or, you know, info, that's all, I mean, it all falls under feedback, but it may well be that that feedback, in some ways is again, very sort sort of collinear with risk, if you're saying, well, one of my risk metrics is how often do we get an exception thrown that we track in our exception tracker or whatever, and then that's part of the feedback.
Ben Rady: Mm hmm.
Matt Godbolt: And it's also, it contributes to the risk is do do you see those as being non orthogonal in that way? Or?
Ben Rady: Yeah, absolutely. So one of the things you can do is you can mitigate risk by adding feedback. right So if you have better observability in your system, right you have better application metrics, you have better alerting, you have better things like that, then you can probably take more you know you can have more risky things that don't ah result in as much risk because you'll be able to respond to them quickly.
Ben Rady: Like we're going to put this strategy into production.
Matt Godbolt: Right. That's interesting. Yeah.
Ben Rady: If it starts tanking, we'll know about it right away and we can turn it off. Or if the exception starts happening, we can we can handle it right away. Whereas if your feedback is lower because your observability is lower, then that risk is effectively higher because you can't see what's going on, right?
Matt Godbolt: Yeah. Yeah. Yeah. That's interesting. Okay. So, all right. And then we've reached CRUF.
Ben Rady: The T, yes.
Matt Godbolt: What is the T?
Ben Rady: The T in CRUFT is...
Matt Godbolt: Teams, I remembered it. I'm a good learner. Team or teams, yeah. So um so the bigger the team, the better. I i see, yeah. So you're trying to maximize the number of...
Ben Rady: Well, actually, yes. So here's the thing. The answer is sort of yes, but not really yes. So obviously, we know that big teams are bad. But why are they bad?
Ben Rady: If you have a team of 50 software engineers working in a code base, you're going to have to do a lot of things to make that work.
Matt Godbolt: yep, yep.
Ben Rady: So the thing that we're actually trying to maximize here, and I chose T because it fits the acronym, but it's yes.
Matt Godbolt: I was gonna say, I mean, once you've got to CRUF and you're like, what now?
Ben Rady: Yes.
Matt Godbolt: ah
Ben Rady: So I'm trying to i'm trying to think about, OK, so we're we're talking about complexity.
Matt Godbolt: Uh...
Ben Rady: We can measure that with lines of code. We're talking about team. Team is a little bit of an abstract concept, concepts but I think it has a very clear, quantifiable thing, which is bus factor.
Matt Godbolt: Okay.
Ben Rady: You are trying to maximize bus factor.
Matt Godbolt: Can we, can we stop, let's stop talking about buses running people over. We, you know, you, you and I know that the way that we used to do kiddos in our, in an old job that we were in together was the crypto factor where some arbitrary coin that somebody had bought on a whim because it had a funny name goes massive and they never have to work again.
Ben Rady: Yeah.
Ben Rady: The crypto factor, yeah.
Ben Rady: Uh-huh.
Matt Godbolt: And so they, they retire and that's slightly less, um, uh, injure-us...
Ben Rady: Injurious.
Matt Godbolt: Ah, injurious. Yes. But anyway, the the point is that if somebody leaves for whatever reason, and you have a massive hole in your ability to maintain and continue to develop your software or support it, then you have a problem.
Ben Rady: Yes. Right.
Ben Rady: Yes.
Matt Godbolt: And yeah, we can call that bus risk. We can call it crypto risk.
Ben Rady: I like crypto risk.
Matt Godbolt: um Although then now that that brings it a whole other thing.
Ben Rady: Crypto risk is good.
Matt Godbolt: So I get it, it's sort of politically charged something, but whatever.
Ben Rady: Well, yeah, that's true. Lotto risk, lottery risk.
Matt Godbolt: Lottery risk. Yeah, that makes sense.
Ben Rady: Yeah. I mean, what's the difference between crypto and the lottery?
Matt Godbolt: Uh, again, wrong podcast. Wrong podcast for that.
Ben Rady: Yeah, yeah, yeah.
Matt Godbolt: Um, yeah.
Ben Rady: um But yeah, so I think that that number, you do want to maximize, and it is generally a, a I would guess, I'm not a you know modeler of of mathematical things, but I would guess that it is generally a multiplicative factor on the other things, right?
Matt Godbolt: Right.
Ben Rady: So like, how how many people do we have that can understand the complexity that we have, ah manage the risks that we have, add new functionality use cases to our system, you know and interpret the feedback and know how to respond to it,
Matt Godbolt: right
Ben Rady: That is the number of people who are in that sort of, you know, Lotto risk set, right?
Matt Godbolt: That's interesting. Yeah. Yeah. You could even sort of go along as as far as to say like, let's go through all of the issues that we have outstanding right now. How many of them could more than one person, I could I assign to more than one person and they would get it done.
Ben Rady: Right.
Matt Godbolt: And that would give you a way of saying like, well, and you could do it for everyone and kind of build a, a pattern of the entire team, which team members can solve which bugs or issues or things that, you know, risks that you have and go, where are my blind spots here?
Ben Rady: Mm hmm.
Matt Godbolt: Oh. if Trevor, if Trevor ever quits, we're doomed because nobody knows what Trevor's doing, you know, or whatever. And that then, okay, and so I think there are ways you could build to quantify it might be, excuse me, might be a bit trickier than the other ones, it might involve a little bit more gymnastics.
Ben Rady: Yeah, yeah.
Matt Godbolt: But I do think it could be done. I mean, you could even have like labels and get whatever and say, hey, it could be done by blah, blah, blah, rather than in assigning it to people specifically, and then go, hang on a second, which, which, which issues do we have that only has one person on it.
Ben Rady: Right, right.
Matt Godbolt: Yeah. Yeah. Oh, whatever. Yeah. Yeah. Sorry. I'm trying to solution this right now, but no, I like it.
Matt Godbolt: So: CRUFT.
Ben Rady: Yeah, CRUFT.
Ben Rady: And I think if you try to relate this back to what a lot of sort of colloquial uses of technical debt are. So like going back to the original thing here, but you got a room full of six people and you got 12 opinions about what technical debt is. Those opinions are are probably not wrong. They're almost certainly not wrong. They're probably born from direct experience and sort of Hard-fought lessons it's just that they mean different things but we're using the same word to refer to them right so a real basic example of technical debt as many people use it is essentially abandoned where right like you got the haunted graveyard project where it's like you know.
Matt Godbolt: Yeah. Yeah. We've mentioned this. Yeah.
Ben Rady: In that situation that the T factor has gone to zero right.
Matt Godbolt: Yeah. And it's all risk all the time. Uh, yeah, there's not really, and I mean, maybe you're getting a small benefit.
Ben Rady: Yeah, yeah, you can't manage the risks anymore. You can't manage the complexity anymore. You can't add new use cases to it anymore because T is now zero, right? um Another situation is when things get too complex, right?
Ben Rady: Like the complexity factor goes way up. It becomes very hard for people to understand. And now you can't add new use cases to it anymore, right? Because you're by doing so, you're probably taking on a risk.
Matt Godbolt: Yeah.
Ben Rady: I can go in and I can change the software, but I don't really understand how it works. If I break it, that's going to be really bad.
Matt Godbolt: Yeah.
Ben Rady: So all of those dimensions come into play in that and that scenario. And there are other things, like I need to get something done quickly. How do I get something done quickly? I implement the happy path for a use case, and I don't worry about the risks.
Ben Rady: Right?
Matt Godbolt: Yeah.
Ben Rady: I say, like we're going to catalog these risks. Hopefully, we're going to address them at some point. But this thing this functionality needs to exist by Friday. And I'm going to implement only the minimum amount of code that I need to to make that work.
Matt Godbolt: Right.
Ben Rady: And I'm going to take on a bunch of risk in order to accomplish that.
Matt Godbolt: // TODO: check password here.
Ben Rady: Yes, exactly.
Matt Godbolt: Yeah.
Ben Rady: Exactly, exactly right.
Matt Godbolt: It's fine for the investor meeting.
Ben Rady: Yeah.
Matt Godbolt: It's less fine when they say, how quickly can we get to production?
Ben Rady: Right, right. so So this is my my next my next iteration of the of this thinking because I do think it's a shame that the phrase technical debt is so sort of like blurred in its meaning, right?
Matt Godbolt: No, I like it.
Matt Godbolt: But it it means it fits if, but it does fit a lot of cases and it's very easy to talk to non-programmers.
Ben Rady: We're programmers.
Matt Godbolt: I think we, you know, we we litigated this the last time around.
Ben Rady: Right.
Matt Godbolt: I mean, everyone has sort of some gut in understanding of what I say when I say like, "Hey, I'm going to do this quickly, but it's going to cost us in the longer run". And you're like, "Oh, I get it. You're borrowing from some mythical thing and that puts you in debt." And later on you have to pay it back with some kind of interest, which again, we've said doesn't really exist in the same sense, but like it doesn't, it does. bring some of the thought processes through, a not thought, process it it ah does have the right kind of smell to it, right, for for for for it, which is why it's so attractive.
Matt Godbolt: CRUFT, obviously, is a great acronym, and it is an acronym, I just had to think to myself.
Ben Rady: That's its main strength, really, is the acronym.
Matt Godbolt: But also, it is a word that we use to mean exactly that. And so if we call it "cruft",
Ben Rady: Yeah, yes.
Matt Godbolt: But I mean, the thing is, it does, I mean, to, to, to pick holes, uh, it is still an incredibly broad set of things that you've just defined in that, which is fine because presumably you're covering, ah this is like all things. In fact, CRUFT in this instance is a an all-encompassing aspect of the entire project, right? It it covers all of the parts of it, the good and the bad, because you've got the you in there that's a usage, and you've got like the feedback, which is usually good, and and the team, which is hopefully a good thing. And so it's not like ah it isn't in its own right and negative sense. Like if I say, oh my gosh, this is a bit this is a lot of cruft here.
Ben Rady: Yeah.
Matt Godbolt: Obviously, colloquially, we know what we mean when we say "cruft". We mean it's like you know it's the belly button lint of the code phrase.
Ben Rady: Yeah.
Matt Godbolt: It's like there the goo around the edges that you have to pick out. Um, but so yeah, I guess it's a good acronym to think about how to um how to run a project and think about when you're when you're making a decision about whether I should add a new feature or whether I should test this in a particular way or whether or or not, we should just send Trevor off on his own Odyssey for three months and then see whatever he comes up with. You can measure it using the cruftometer and say, are we OK with this? Are we still within the bands of cruftiness that's OK? Maybe that's how you could accept this.
Matt Godbolt: Like: We accept that all projects are crufty because they're programs, right? And they're written by humans. And they're an engineering solution to ah a very high dimensional optimization problem of like, Well, we need to get this out by Thursday. Oh, I don't really understand how this thing works. All right. I'm going to use a library. I already know all these kinds of things are being balanced and I had all the time. Um, yeah, I suppose I'm trying to rationalize what CRUFT really means.
Ben Rady: Yeah.
Matt Godbolt: I know, you know, it's a great acronym.
Ben Rady: Right, right. Well, so here's here's how i'm intending here's how I use it myself, and here's how I intend for other people to use it if they choose to use it, which is if you're talking to a non-technical person, use technical debt as a metaphor.
Matt Godbolt: Okay.
Ben Rady: That's great. like That's what Ward originally intended. That's a great way to describe to somebody who's not a programmer why you're doing things other than adding new functionality that's going to potentially make you money. It's like, why are you guys refactoring? What's refactoring? Why are you spending your time? Use technical debt. It's great. That's what it's for. If you have programmers talking to other programmers about the trade-offs that they are making in code, you can do much better than saying, ah, that that thing's got a lot of debt. You can be more specific because you're a programmer and you should. So for example, if you are reviewing a PR and you see ah some code in a PR and you're like, I don't think this complexity is worth the use.
Ben Rady: Like you added in this super complicated arg parser thing instead of just slicing off the first two string parameters. And you added like 10 lines of code and it's like, I get that that's better, but I don't think it's worth the complexity, right? And then you can have a discussion about whether that's true as opposed to like, this code says it's full of debt.
Matt Godbolt: Well, yeah, right.
Ben Rady: I hate it, right?
Matt Godbolt: Right. That, that makes a lot more sense to me. yeah Yeah. Essentially you're handing someone a cheat sheet of things to talk about when either justifying a decision or considering tradeoffs and, you know, in a code review situation, these are the words that you should be using. You know, this seems risky. Or are we okay with the risk that that this thing won't work? Is it tracked in an issue somewhere? If it does go wrong, do we have the feedback that will tell us how to come and find it quickly?
Ben Rady: Mm hmm.
Matt Godbolt: um Who else knows about this? Does anyone else understand this piece of code? um You know, is it could it be less complicated than this? Maybe we should just is there something on the shelf off the shelf we could already use, right?
Matt Godbolt: And I've presumably missed one of the letters in this. this example or Yeah, who even asked for this?
Ben Rady: Yeah, right.
Matt Godbolt: Is this something we wanted to do?
Ben Rady: We've been asked for this.
Matt Godbolt: yeah Yeah, I think I got them all now.
Ben Rady: Yes, right. Why are we doing this in the first place? Yes, yes.
Matt Godbolt: Yeah.
Ben Rady: And going back to the start of this conversation, I'm just suggesting that this is a better pattern. If you want to think in patterns, this is a better pattern for programmers to talk to other programmers about aspects of their code that they either want or don't want.
Matt Godbolt: Yeah.
Ben Rady: Right, as opposed to just debt, which doesn't have a concrete enough definition or isn't as concrete as programmers are capable of talking about.
Matt Godbolt: Yep.
Ben Rady: We are capable of talking about lines of code complexity. We are capable of talking about potential risks like, oh, if we get this message type, we don't handle it. What will happen? Oh, the system will restart and it'll go into the dead letter queue. Okay, that's an acceptable risk. Great. right We are capable of talking about these trade-offs in more specific terms that isn't a metaphor, a financial metaphor, and we should. And if you don't like cruft and you can't remember what the words are, that's fine. You should come up with these terms for your own team. right like For your the group of people who are going to be in this code together, who are going to be wearing those w risks, who are going to be getting those pages in the middle line, come up with your own terminology for this.
Ben Rady: But you don't have to use the same metaphor that you use to explain to the CFO why you need another person on your team that you do when you're talking to another programmer about code.
Matt Godbolt: Yeah, there it's just lazy to to use use debt.
Ben Rady: Yeah.
Matt Godbolt: Yeah, I know we use it colloquially. Yeah.
Ben Rady: Yeah.
Matt Godbolt: No, I'm i'm with it. I'm with it. um I don't know how to weave this in, but it must be said.... "Oh, no", he says, Ben, I can see the look on your face and...But ah just ah just for for our international audiences, I believe we we we have, um you should know that Cruft or Crufts is a dog show in the UKIt's the equivalent of the what is the the big dog show in the the u US? s I'm trying to think what it's called now.
Ben Rady: Oh yeah, like the Kennel Club something I don't. [Westminster Kennel Club show]
Matt Godbolt: Is it Kensington? No, I feel there's something else now. and Now I should have, I was going to try and Google it, but in this particular position, my keyboard is so close to the microphone. All you'd hear is at the clacketing. But yeah, so whenever we say cruft, it's exactly what I think of. In fact, you know, ah two two, three jobs ago, we had the, C++ library of things that C++ really should come out of the gate gate with, you know, command line parsing and printing strings with commas between them and stuff like that, was called ccruft, as in crufty bits of C and C++ that were just like, we just needed to do this because it's pasting the language together. So cruft is well, well taken, one not well understood, but I don't often think of the dog show whenever anyone talks about it. So if you can come up with S on the end of your acronym, if you need another thing, then that would make my day.
Ben Rady: CRUFTS?
Matt Godbolt: um yeah But it then it would lose the it would lose the ah the the the the programming meaning, so maybe not.
Ben Rady: um i'll workshop but
Matt Godbolt: No, that's awesome. um Consider me a convert to CRUFT.
Ben Rady: okay well i I appreciate trying to poke holes in this because the temptation with all of these kinds of things is you know like you're you're you're building castles in the sky and they're not really applicable. And like I try to think about things where it's like, is someone actually going to respond in a PR using these terms, the way that they've defined them here, and result in a better conversation and a better solution? And if that's not actually happening, then you're just
Ben Rady: You're just wrapping yourself around an axle being like, oh, and then I'm going to define this like this, and I'm going to do this like this.
Matt Godbolt: Yeah.
Ben Rady: And it's just systems that no one cares about.
Matt Godbolt: No, i think I think it's valuable. I mean, these are these are not... No disrespect to your insight here. These are not novel concepts, right? You've just found a really good way of putting five key of them key concepts together that make sense and have a catchy acronym, which is a great way of you know um of making it memorable and giving you a conference talk to prepare for, which I'm accepting expecting anytime soon then.
Ben Rady: Right. Yes.
Matt Godbolt: so where you know where Where is this going to be presented?
Ben Rady: Right, right, right.
Matt Godbolt: Well, you've already presented it internally. so
Ben Rady: Yeah, yeah, no, i should I should present this somewhere. But yes, the very fact that it is not novel is is a good sign. Because again, this was all about me taking the things that I intuit.
Matt Godbolt: Yeah.
Ben Rady: And I'm not special. There are lots of other senior software engineers who have built things for a long time, internalized this stuff. And they sort of intuit things in this way. And it's just taking those and just putting a name on them.
Ben Rady: So right like we're not doing anything new or interesting here.
Matt Godbolt: yeah I think.
Ben Rady: We're doing things that we've done for years, especially some of the risk management stuff. it's like years and beyond software, years and years and years. We're just giving it a name so that when we talk about it, we can say, yeah, I think this is too complex, or I think this is too much a risk, instead of like a very long-winded explanation of all the things that no one is ever actually going to read in a PR because they're just like I TLDR.
Matt Godbolt: Yeah, yeah, yeah.
Ben Rady: Yeah.
Matt Godbolt: Well, cool. I mean, that seems like an ah an obvious place to to to to close this thing. And I'm going to go in and think about this more. i I'm doing a lot of Compiler Explorer work at the moment, which has someone in a region of 800 open issues, about 40 open PRs.
Ben Rady: um my god
Matt Godbolt: And ah yeah, so um this gives me a new tool in my arsenal to start thinking about things there. that I mean, there is a project, my friend, that has a lot of you, for sure, but an awful lot of people have added a ton of things in that are useful for them. And then they've disappeared off the face of the Earth afterwards, which is completely reasonable. It's an open source project. You know, you add your thing. but we don't necessarily have the test to cover those things, which means that they may break and we don't know.
Ben Rady: Oh my god.
Matt Godbolt: And that is a big R and it makes it hard for us to change things.
Ben Rady: Oof. Uh-huh. Uh-huh.
Matt Godbolt: And so, you know, this is ah what I'm going to be looking at over the next few days is trying to work out how to bring this beast back under control so that that we can make make it more um or less CRUFTy, more CRUFTy, I don't know: better.
Ben Rady: Better.
Matt Godbolt: Fantastic. Well, um I guess I will see you the next time we do this.
Ben Rady: Yeah, see you next time.