Hey, Ben,
Hey Matt.
We, uh, we haven't really thought about this, have we?
No, I mean, not really.
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
That's the extent of the planning.
Thta's the extent of the planning. So let's talk about technical debt.
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
To soapbox?
Yes
I could get behind that,
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,
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?
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.
What's the TLDR of that
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.
Um, and that is quite different from the way that certainly I colloquially use the term technical debt.
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.
Right.
Very few people are actually, we were talking in a prior episode about incremental.
I was gonna say, it seems to sound very..yeah..onn theme for that.
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.
Very much so. Yeah.
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.
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.
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,
We'll take on some, debt you take it on advisedly, right? Yeah.
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.
Right.
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
. 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.
Yeah. Right. But
I guess it, it's, it's entered the zeitgeist of programmers. Mm-Hmm.
Yes. It has.
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 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
Yeah. Yeah.
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. So I'd rather get there with some amount of like, brokenness Mm-Hmm.
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.
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.
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.
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.
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.
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
, 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
Functionality. Yeah. Right. Well,
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.
Right, right. Yeah. I mean,
So anyway, the facilities, yes. Facilities, no capabilities.
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.
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 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.
Um,
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?
Absolutely. Yeah.
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
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.
Well I would put that in unnecessary complexity, right?
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.
Mm. Well, yeah, that's,
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
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.
I mean, first of all, um, I, we should note that Perry [Ben's dog] has just made his first podcast appearance.
Oh, has he?
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
Mean, did he walk back out again? I,
Yeah. I didn't notice him go out, but I thought I was like, Hey, it's Perry
He's probably somewhere in here. I don't know.
Anyway, um, I've now forgot what we were talking about,
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...
The issue tracker.
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
.
Like there are other more sophisticated ways code to metric complexity,
Not a bad proxy.
It's not a bad measurement of complexity. Yeah. Right. Yeah.
Yeah. Fair,
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.
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.
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.
Yeah. Yeah. And there's a lot of, yeah, we've, we, we've talked about FUD sort of before Mm-Hmm.
No, that's true.
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.
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.
Right. Right. But
It does. Yeah. But it's so easy. It's a trap to fall into. I mean, I, I can, yeah.
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.
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.
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
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,
They're not sending cryptic messages to each other and
Not, in this particular example
And no one is trying to intercept it or whatever. But they're two regular programmers on the team
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.
I mean, the one that involves sitting in the park is better, just, you know. Yeah.
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
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.
Mm-Hmm.
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.
Yeah.
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.
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. 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.
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.
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?
Yeah. That's never a,
It's never on that board,
Is it? Very rarely. Very,
Very, very rarely.
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.
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,
.
Right. It's not as good, but it does the job, but
It does the job. And more
Importantly, it'll save, save us this giant chunk of complexity 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.
Right. Right, right, right,
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,
,
And you have a whole
Phoenix from the ashes of the previous system with all the same flaws.
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,
Right? Yeah. Yeah. We, we, we actually, we turned it around, uh,
Right? Yes.
It is. Just, it's, it is, it's a haunted house on purpose. Right. You know? Yeah. It's like
The Halloween haunted house where you go there. It's just a fun time.
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,
That, that is scary.
,
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.
That's, and
That's by doing so it puts a constraint on what those things can be.
Yeah. Okay. That's fair. Right?
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
It's, and then you can go and get it. But so
Actually quite difficult to remove from the source control. So
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.
Mm-Hmm.
Right.
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 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.
To make the integral of the area under the graph.
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.
Right. Right. So
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.
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.
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
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.
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.
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 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?
Is this when you have your one-on-ones with yourself
In the shower
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
Or sitting in the park next to Alice.
All right. Yeah. Feeding the ducks with Alice. Alright, that sounds like a perfect place for us to finish. Yeah.
Cool.
See you next time. Bye.