The best analogy for technical debt is debt - that is where it got the name from! Just like financial debt, technical debt is not necessary a bad thing, but a tool - and something to manage, control and track. And just like financial debt, taking out too much technical debt without paying it back can crush you.
There is nothing wrong with taking out a mortgage (and thus getting into debt) to buy a house - you just need to understand how to pay it off. Similarly, if you start a startup trying to find product-market fit before running out of money, there is nothing wrong taking on technical debt to do so, as long as you understand what you are doing.
The problem with this analogy is you don't necessarily take on technical debt when you make your technical decisions. Technical decisions only become debt when you have to revisit those decisions. You don't pay interest on debt over time. You pay interest whenever you build upon or modify the flawed code.
You can write the shittiest spaghetti code in the world, and if you never have to build upon - or touch it again - you took on zero technical debt.
In comparison, if you write just slightly flawed design, but build out your complete featureset based upon that flawed design, you could have mountains of technical debt.
I think a better analogy is building a structure. If your code is foundational, you better get that shit right. If you cheap out on a $20 part and have to replace it, but it's just a door knob, that's not too bad. But if it's under your slab on grade foundation you're going to pay thousands to dig it up and fix a $20 part.
* Contagion. How much it spreads over time. If a piece of tech debt is well-contained, the cost to fix it later compared to now is basically identical. On the other hand, some forms of tech debt keep giving. Image if your string type has some issues.
Linking that back to the debt analogy, there are different interest rates for different kinds of debt, depending on how contagious that part of the code is.
The only code you never have to touch again is code nobody is using. In which case, it's like a corporation declaring bankruptcy: the debt becomes moot.
Otherwise, you always have to deal with it eventually. Look at the Y2K problem. or how the 2038 problem is starting to crop up already, exposing significant levels of technical debt. https://twitter.com/jxxf/status/1219009308438024200
I also think technical debt does accrue interest over time, albeit not as linearly as a modern installment-plan debt does. That's because it slowly falls out of sync with people's memories. With libraries, with operating systems, with techniques. Bad code I wrote 10 minutes ago is pretty easy to clean up. But the next day, the next month, the next year? The cleanup gets more expensive. At some point the work becomes more archaeology than normal programming.
It's also true that actual foundations have something in common with foundational code. But that's a different aspect of programming than what tech debt is pointing at.
> Most operating systems designed to run on 64-bit hardware already use signed 64-bit time_t integers. Using a signed 64-bit value introduces a new wraparound date that is over twenty times greater than the estimated age of the universe: approximately 292 billion years from now, at 15:30:08 UTC on Sunday, 4 December 292,277,026,596.
There's a pretty clear ship date, after which you never touch it again.
Even in the world of SAAS, there are plenty of services or libraries that you write that serve a single purpose, are good enough, and never get touched again.
Well, some video games, those based on a historical model of actually shipping physical games. But successful video games these days can literally run for decades, either directly (as Warcraft) or as a series (like Madden NFL). Plenty of things that are intended to be one-and-dones also evolve, like Stardew Valley's audience demanding multiplayer.
Even the code you mention isn't a great example for your case. In theory it was throwaway, but now that it's out there, you can bet that plenty of people will be touching it. And you're also ignoring the path not taken. This beloved game didn't get a sequel, despite plenty of demand. If the code were in better shape, might it have had one?
> You can write the shittiest spaghetti code in the world, and if you never have to build upon - or touch it again - you took on zero technical debt.
I don't really agree with this view; it may seem pedantic, but I think it's better to consider that case as tech debt.
In my experience, it's incredibly uncommon to write code and never touch it again -- particularly if you elect to cut corners in the interest of getting something out the door quicker. That code inevitably either gets retired because it's not being used (your debt was forgiven), or gets built on top of (your debt starts to compound).
If you make a decision to lower the quality bar because "we are not going to touch this again, so it's not tech debt, so it doesn't matter", then I think you're fooling yourself. Instead, I think it's better to assume that you're taking on tech debt (you almost certainly are), apply all the best practices around managing that debt (i.e. catalog it, be aware of your overall debt level, and be aware of tech debt in critical systems), and be happy if your debt is later forgiven if you miraculously never need to touch that code again.
Maybe there's a narrow sense in which this position is technically/semantically correct, but I think more often than not, this position is going to hurt you more than it helps.
> Technical debt consists in performing a fix or development in a quick and dirty way because it takes less time, even though it will make the code harder to work with in the long term.
If you aren't going to be changing the code later, then writing a bunch of spaghetti code won't make it harder to work with in the long term.
How can one accurately predict that the code won't be changing in the future? If you needed to get something done once, isn't there a good chance that in the future someone else, including your future self, may need to rely on or modify it?
It’s contextual. E.g. if you’re in a situation very similar to past situations where you threw the code away afterwards, you can be pretty confident that you’ll throw it away this time too.
The difference though is that financial debt is very easy to measure and quantify but technical debt is not.
I like the Tetris analogy because that game has a type of debt that anyone who has played it can understand, yet is not as easily quantifiable as financial debt.
I guess the analogy still works because not all debt is monetary.
You might owe a debt to the mob. Perhaps they help you out of a sticky situation but let you know that some unspecified favor will be required in the future. So you have a debt, but what exactly you owe is loosely-defined and might cause great chaos in your life at some inconvenient point when it's time to repay.
While I fully agree that financial debt is easier to measure, and some forms of it are very easy to measure, I don't think it is always very easy to measure. Perhaps it may be a difference in what counts as debt, but I see many people engaging in decisions that require future payments without considering those payments at all, much less viewing them as debt. For example, getting a pet dog can have numerous costs associated with it but people don't always consider these as debt. And the average person (fully based on my own personal anecdotes) isn't going to be willing to give up the dog just because it is costing them money. So while there isn't a legal due that you can be taken to court for, I still think it counts as a form of debt.
Then should we talk about technical liability and compare it to financial liability? Maybe that would be a closer comparison than using debt in both cases.
I personally like "deferred maintenance". Similarly doesn't have a monetary value to it, unless you actually do a check-up where you could calculate it (man hour estimations).
That's a good point. I think of any given project as a CDO. There are good, productive debts and bad, stinking, potentially crushing debts in there. What matters is not that there is debt - I think there will always be - but what the blend is.
If the debts were thoughtful and deliberate with understood risks, they might make perfect sense.
If the debts were taken by people who couldn't evaluate them and had no business making that decision, it's going to be bad.
Odds are the first are well-understood and maybe even documented. The second may explode when the underlying assumptions or risk changes.
Sounds like debt to me. With all the refinancing going on I wouldn't be surprised if there's still some debt out there that can be traced back to someone centuries ago that hasn't been payed back yet.
I was going to say the opposite, just because you'll "pay it off later" doesn't mean you're not paying for it now, with every single change taking longer than necessary.
Or the unit of measure. It's really hard to tell what sort of technical debt you are taking on and building for contingencies that may never manifest is it's own type of sunk cost. That's (a) why projects need to have some strategies that move forward without excluding lateral (or minor-backtracking) moves, and (b) why software development is inherently hard.
It's more like a compound interest. A financial example would be payday loans with an incredible APR and a low monthly payment, your debt is forever increasing.
And I might add: what is technical debt in one project, maybe isn't in another project.
Engineers sometimes want to overengineer things that would work just fine in that situation. I remember an old link about someone studying the source code of a game (Doom maybe) expecting to find beautiful solutions for every minor problem when in fact he was surprised by how most of it was straightforward.
Check what needs to scale/be resilient before reinforcing the code there (and of course, if the solution is already frail at the moment it probably needs to be fixed sooner rather than later)
I live my coding life by this philosophy: The best code is the stuff that looks like any novice could have written it, but only an expert knows how hard that is to do.
(bonus: write your code like the next person to work on it is a psychopath and they know where you live)
> financial debt is very easy to measure and quantify but technical debt is not
For business school grad PMs I like to see if they can run with an analogy to selling unhedged call options rather than thinking of it in terms of debt with a known payoff schedule.
Even the bankers got derivatives wrong at an epic scale.
I wonder if there was a time in history where financial debt was not well understood. This would have to be either before the invention of algebra, or possibly also during a time of very poor education.
> or possibly also during a time of very poor education.
So, you mean today? The number of students that take on crippling amounts of student loans without truly understanding how it will affect them is staggering to me. The ease of obtaining credit before a person truly understands how devastating 20%+ interest rates are is also pretty telling. Financial debt is easy to get wrong, and is only compounded by the fact we don't teach this as a basic course in primary schools.
Even worse, many think they understand finances without realizing there is a difference in corporate versus personal financing. The rules don't necessarily transfer between them.
Or just large numbers. A valid strategy to invest a million will be worthless with just a dime. No matter what the silly myths of success say.
A monetary metaphor for technical debt implies a freedom to the order of addressing technical debt that is deceptive. This comes from money's fungible nature: if you have many debts, you can pay off whichever debt you want and you can pay it off in parts.
I think this metaphor does a good job of capturing the path-dependant nature of debt. How the size of each individual debt sits in the shadow of the code that relies on the flawed code. Understanding that there's the work of fixing technical debt and the work of getting to the place where you can fix technical debt feels more clearly communicated by tetris than by financial debt.
Financial debt is a good analogy, but there is a crucial difference: technical debt is not fungible.
Cleaning up one kind of issue in your code doesn't affect other kinds of issues, and you can end up with fundamental architectural problems that no amount of testing or clean up can compensate for. You can handle some issues incrementally (eg adding tests), but some issues are going to be so fundamental to your system that you can only handle them by making a lot of changes all at once.
In this analogy, game development is like taking on crippling amounts of debt, declaring bankruptcy, and then starting a new company to do it all over again.
And just like real debt, you can just walk away from it at any time with no obligation right, not even on your credit rating? Just look at the debt and say "don't want you no more" and the debt says "aw shucks. Guess you don't feel the benefit of paying me. I can understand. So all right.
I won't complain.", and the debt goes and disappears, down some dark alley with a bottle of scotch, no debt collectors ever hound you about it, and you never hear from the debt again.
That kind of debt, right?
But wait there's more! I forgot to mention that even if you walk away you get to keep what you bought on credit, without any further payment of any kind and it continues working in its current state, forever - you just can't improve or renovate it if you walk away from the debt.¹
That kind of debt, right? If so then perfect analogy.
-
¹ literal lie though, yes you can. you can totally still improve it real quick. I'm afraid I'll have to add $150,000 to your technical debt though, which you can walk away from any time. still want this real quick $50 change though? It might be $50 but it's $150,000 in debt though.
Sure, defaulting does decrease your credit rating, as your example of 50 $ change for 150000 $ more in debt illustrates.
And yes, there is a point further borrowing will be rejected, as sibling comments in this thread mention.
So, excluding the actual strawman numbers, analogy still holds very well.
I "defaulted" on the loan of replacing a script I wrote in 2 minutes in autohotkey (a windows scripting language). I'm never going to write it properly.
Now explain to me how defaulting on this technical debt has hurt my credit rating.
Is the next time I open a new autohotkey script is it going to say to me "Now wait a minute. What about all the debt you defaulted on last time? I'm not going to let you write a quick and dirty script! You'll default on ever rewriting it! Go do it properly as a source controlled project in Microsoft Visual Studio. I am not letting you write another script."
Is that what happens? No?
That autohotkey script is running now. Where's the debt? How is my credit rating worsened by defaulting on it?
It's debt you can default on at any time without any consequence, while being able to continue to use what you bought on credit.
Your version is like saying that the minute a squatter takes up residence in an abandoned building, he's just gotten $140,000 in debt, the cost of buying some land nearby and building a proper, albeit unfinished building with no electricity or heating.
And if, still in his abandoned building squat, he finds and burns some wood in the winter, watch out! He's just added $25,000 in debt to the $140,000 he already had, since that's what a proper HVAC system will cost in his properly built building. He went from $140,000 in debt to $165,000 in debt the minute he set fire to some wood.
But that's clearly very wrong. Maybe he'll live in that abandoned building for 4 years and then just walk away. Poof. The $165,000 in lousy-analogy debt disappears the moment he walks away.
In general, I'd agree with that assessment, but the debt-based metaphor also reaches its limits in a couple of cases.
One of which is that it is often really hard to quantify, but that does not seem to stop many non-technical manager types from trying to treat it like financial debt nontheless.
Another one is that unlike financial debt, which should be controlled by various organization-internal mechanisms, tech debt is often not something management is conscious about (at least when it is "created"). I've seen far too many examples of horrible code that can simply be explained with lazyness or incompetence, but I'm pretty sure management never called for a hard to use, unnecessarily complicated API.
Also, if the tech debt is caused by management, it is usually an implicit byproduct of unrealistic time constraints, and I'm pretty sure in those cases they would often choose find another solution too if they were conscious about how bad the problem they're creating really is.
Edit: Either that, or their incentives are way off because they don't have to deal with the consequences. Which is also the real cause why financial debt is usually strictly controlled.
The old 25% rule (don't take a mortgage unless it is no more than 25% of your income) is ignored all the time. My mortgage was right at that, and I generally have never had trouble coming up with it. If I was doing 50-70% like some of my California friends I'd be as nervous as a rat at a cat farm. So I think you have to set some reasonable amount of technical debt as you say. Some issue simply dissolve, others get worse as far as the debt goes. Sometimes the business goes in a different direction and more dissolves. Other times maybe a big deal comes in for one of your products and you realize it might not be as easy to update for new needs (and $$ of income in particular) so you don't want to let it build up too much.
The problem to me is this covers your language choice as a debt. You are literally borrowing against the knowledge in the standard library of your language choice. You may have to leave standard someday based on growth or success.
Most of what people call debt, though, is really just comprises. Which works, to me, as you can just say the code is too compromised. :)
Another thing worth noting is that company success doesn't mean you're more easily able to pay off the debt like you would your mortgage. In fact the opposite may be true and it may limit future earnings if it bites you in the wrong place.
There is nothing wrong with taking out a mortgage (and thus getting into debt) to buy a house - you just need to understand how to pay it off. Similarly, if you start a startup trying to find product-market fit before running out of money, there is nothing wrong taking on technical debt to do so, as long as you understand what you are doing.