How far can we stretch technical debt?

Technical debt is a metaphor used to explain the tradeoff we all face when we have a deadline. How much is it worth to rush the code out the door? It's a good metaphor, but the term is often used these days to mean 'code I don't like'. In this episode, I examine the parts of the metaphor and ways in which technical debt differs from financial debt.

Transcript

How far can the metaphor of technical debt be stretched? Hi, my name is Eric Normand and this is my podcast welcome today. We're gonna be talking about technical debt and some of the issues I See with it with the way it's being used these days So Let's talk about first What the actual metaphor is? Okay, people will use the term technical debt a lot. They usually mean we have a big messy code base or you know some other Technical aspect maybe their database that needs some some clean up But there's actually a real structure to technical debt it was first used to explain to business people the idea of Having to clean up code so It's about it's like a loan right You can take out a loan a business can take out a loan to be able to do something sooner than you would be able to if you Had to wait to save up that money Okay, so instead of saving up now and then in six months say be able to have the lump sum to buy a thing you can take a loan by the thing now and in essence save for the next six months by paying the interest in principle down on your loan, right? so In the same way we can get code out sooner by taking on technical debt and Then we can learn from that code So maybe the custom whether the customers like that feature or whether it could you know even work at all It's like a prototype and then pay off that principle down the road as we go along So that is the idea now, what is the principle and what is the the interest the interest is the amount of time? It required it cuts down. Let's say the amount that it cuts down your velocity Right, so your code is a little bit off It might be messy. It might you might have learned something You know the programmers might have learned something like oh actually users want XYZ instead or That oh, there's a better database structure Then what we initially did so you'd have this learning in your head and now you have to The interest is the cost of working with a Non-optimal model because your code doesn't reflect what's in your head so if you wanted to work the way it's in your head you're gonna have to Add extra code take more time to adapt Your new features to the poorly structured database Okay, but then what's the principle the principle is actually going in and taking that learning and Putting it into your code. So that's gonna cost a certain amount of time to do Okay So that's the initial metaphor once you've paid down the principle. There's no more interest You can work at full speed, but when you've got some principle Then you have to pay interest meaning you're gonna be a little bit slower at maintaining adding new features, etc Okay People use it loosely now They this was the original metaphor this idea of getting some learning by shipping faster Like shipping something that maybe you don't understand completely Shipping it getting some learning and then you're gonna have to pay down that you're gonna have to pay down that debt by Taking your learning and incorporating it back into your system People also saw that we could get a feature out faster In the same way Not to get learning But just get to get it in the hands of the customers and be able to charge them for it by doing a sloppy job Right by just getting it done whatever way seems to work and not Designing it so well Right and so that that's another form of technical debt where now your code is a mess and It doesn't have a coherent design to it and it was to be able to get more more users or more money from the users and Now you're gonna have to pay down that principle or continue to pay the interest forever Okay Nowadays people just talk about technical debt as just the mess the mess of code I don't like the code. It's got a lot of technical debt. It's basically code. You don't like Which is not really? Helpful it's stretching the metaphor way too thin All right, but there are some things that Some ways that technical debt Works differently from Regular debt financial debt, so I'm gonna list a few of those So let's say you have a feature that to do it really well Would cost 30 days of a developer's time But you're not sure whether it's worth 30 days you don't know if the users are going to Want that feature. You don't know if they're going to pay more for that feature and So you say well, let's see what we can do maybe we can learn if they like this feature by putting out something in 10 days Okay, so you're gonna save 20 days you're gonna learn faster and What happens you learn? After 10 days that they don't like the feature Boom you can just delete that code You know if you designed it well enough To be separate you can just delete it you don't have to pay it back right it's very very easy to to To just remove that feature Okay, so that's one way that it doesn't work if you borrow money from the bank to Open up a new branch of your restaurant And then there's no customers. Well, you still have to pay the bank back, right? Okay, maybe you could stretch it and say well, you're gonna file bankruptcy But that's not really how it works because then you lose all your stuff when you file bankruptcy All right, here's another issue. Okay, so let's say again you have a feature that will take 30 days and You decide as a business that we need this really fast. Let's do it in 10 days So what have you borrowed? Like what is your principal? Your principal is actually 30 days Right you spent 10 days, but you had to borrow 30 days So to fix this thing to get rid of all the interest payment You would have to spend Again 30 days because you designed it like crap Like it's very unlikely that you'd be able to really use what's there And even if you did it would take time just to figure out how to adapt it so what I'm trying to say is in in The debt metaphor the the financial debt if you borrow $100,000 to open up a new store you spend the hundred thousand dollars on the new store And then you're in debt for a hundred thousand dollars and you have some plan for repaying it over time but if you in The Metaphor in programming you borrow 30 you spend 10 But now you still have to pay back The the 30 it's more than you spent Right you you're borrowing more than you spent which is kind of weird. It doesn't really work the way the way money works Okay, here's another thing Why would someone open that restaurant? because they think that There will be customers to that restaurant and that whatever Income that new restaurant has will be more than the interest and principal payments So it's actually good debt It's good debt because it's paying off. It's paying more than then the cost of the loan and So you could do that again and again and open more restaurants as long as you believe that you would get the customers to Pay off the service on that loan But we don't have a similar thing in in the programming We don't have a thing like so basically what happens in the restaurant is if your growth is If you're the growth of your income is higher than the growth of your debt Then you're doing good. That's why in the US we have this National debt this deficit a budget deficit we spend more than we take in in taxes But our economy is growing and so there it's it's considered okay the economy is growing We're taking on more debt, but the economy is growing faster than the amount of extra money we're borrowing, right? So there's always more new money that we could spend to pay down the debt We don't have that the when you're taking on technical debt It is the interest payment is causing you to slow down It's not like you can get more it's not like you're spending Like Design time or whatever you call that extra time that you're not putting in so you have a 30 day project You decide let's rush it and get it out in 10 days cut corners whatever You're not gaining any speed from that You Your your programming speed actually goes down so the more debt you take on The slower you'll get until you get to zero where you're just basically Treading water keeping the thing running There's no way to spend that Debt to make more Programmer time In the restaurant you can spend the debt to make more Food to have service more customers to make more money. So you're spending debt you're making more money but in in this in the technical debt you're Taking on code Quality debt, right? You're you're taking on negative code quality code messiness or whatever you want to call it and You're not trading that for better programming or whatever more programming so That is that is a problem All right, so another thing that I think that if you if you're really good with the way you refactor and Clean stuff up over time You have you do have the ability to To pay off the debt over time, right? So if I have a financial loan I I have let's say I borrow $100,000 I Can make a plan it's called an amortization schedule that says okay. I'm going to pay this off over 10 years And so this is how much interest and and principle I'm paying down every month Right and and it it starts off with a lot of interest and a little bit of principle and then gradually it turns into all principle at the end Okay, and so you can make a schedule it's gonna take 10 years and this is your monthly payment same every month And so all you have to do is make sure that you're a restaurant That costs a hundred thousand dollars is now making more than that every month and it will pay down that debt over 10 years I Don't think we can do that With debt with tech debt You Can't take that thing that took 30 days Do it in 10 days and now Spend those 30 days kind of over time Cleaning it up because often the the mess you made is so Bad that you have to basically rewrite what you did that's been my experience that You can do it such a rushed job and You learn something like oh, this was really the wrong way to do it You have to now spend the 30 all at once to to move over to the better way to do it So that's another problem. I mean if you're really good with refactoring Maybe you could do it But I'm not I'm not I don't quite see how you could In the systems I've been working on When there's a learning it's often like okay, I learned this thing Those 10 days were worth it, but now I still have 30 days ahead of me to finish it up and You couldn't do it over time. There's just no way or maybe you could do it over time, but it would cost 60 or a hundred It's another way that the metaphor kind of breaks down Okay, and then the biggest problem of all with the metaphor and everyone knows this is that Code quality and Even feature development is all unmeasurable. We don't know how much Design is Worth we can't say how much a feature will actually take until we do it It's all just unmeasurable whereas money. It's very measurable There's still the uncertainty as your business gonna do okay is that restaurant really gonna make money but you You know if it is or if it isn't Whereas with design, what is the value of spending another day? Thinking about a better way to write the software What is the value of good names? We can't really quantify it So the metaphor kind of breaks down there like I've been giving examples Like a thing that would take 30 days and you do it in 10 days that is just You know, maybe with hindsight or if you could play it out in two different Universes where you make the different choices you might be able to do that, but it's all hypothetical We don't know how to measure those things Now I'll tell this other problem, but it's not really the same type of problem So the original Technical debt metaphor was designed to explain to business people who are used to thinking and financing in terms of loans and income and and interest payments and stuff like that it was designed to Explain to them why? What trade-off you were making hey, we can do this faster, but it's gonna slow us down in the long run right But sometimes you need that you need that short-term speed to be able to get a thing out or whatever So it's designed to talk to them and when when I've talked with business people It's never gone that well using I mean using the technical debt metaphor and I think that one of the reasons is that They think they have the idea that messy code is kind of like having a messy kitchen so you have a kitchen and you have to make dinner and For you know a hundred people so you're working really fast. You're making a lot of pots dirty. You're spilling a little bit You know things aren't getting put back exactly where they need to go and You're you're taking a lot of shortcuts because dinner is coming and you need to get it ready by a certain time So then you serve dinner everybody's happy they go home and then you Get out your mob you get out your sponge you start washing the dishes and your You get the kitchen back to a clean state I think that a lot of business people think that making a mess in your code is kind of like that where you Do something quick you have to move fast and you know make a mess and then you have to spend a little bit of time afterwards to clean it up Maybe the same amount of time as it took to make the dinner, right? But you're gonna clean it up Well, it doesn't work that way like I said before if you take a thing that should take 30 days and you do it in 10 You still have 30 days ahead of you to clean it up You Can't it's not just like oh, there's some spills There's some splotches of tomato sauce on the counter and we need to mop the floor It's like oh, we need to rebuild the bathroom. We did a rush job on your bathroom It was so that you could use it quickly, but you know the everything all the pipes leak and Things are put in crooked and We forgot to connect up The right size pipe to your toilet, so it's gonna get clogged and so we have to just redo everything we have to tear down the walls Install new pipes and put everything back and repaint and do everything That's it's more like that It's not like wiping down the kitchen counter. It's Rebuild your bathroom So that is a problem that I Think is is one of the reasons why I don't like to use the technical dead metaphor If if I'm talking to a business person They are often like well, why did you make a mess just clean it up? It's like no, we have to rebuild your bathroom we have to redo the plumbing because we rushed it or We learned something about how the plumbing should be and now we are going to be We're gonna be unclogging this toilet for ever and it's gonna cost a person You know you got a 30 person team it's gonna cost a person to unclog this toilet all the time All right That was my ideas on technical debt I think it's a great metaphor, but like all metaphors it can be stretched too far and then once it becomes cliche people stop thinking about it as a metaphor and they just think of it as a term of art and They don't really understand what it's supposed to be and how it's supposed to be used and I Think it's good to go back and revisit these ideas these metaphors really understand the context that they arose in and then Figure out where where they don't stretch right and I would rather talk about You know having to redo someone's plumbing because we rushed it That to me seems like a much better metaphor for the kind of tech debt that I've seen All right, thank you so much. My name is Eric Normand and Thank you for listening or watching and as always rock on