After reading both this post and yesterday's, I got to thinking more about technical debt.
We all create it. Sometimes for better reasons than others.
It's everywhere, it's costly, and it sucks.
Then I thought about another scary truth that wasn't mentioned in either post:
Much of it never has to be paid back.
That's right, we create "technical debt", but so what?
I often maintain code that's 5 to 10 years old with as many as 100 mods. But just as often, I come across something 10 years old that looks like crap with no mods. How can this be?
Because it works. Somebody wrote a function they needed 10 years ago, and it's apparent today that they didn't know what they were doing. Since then many others have called that function. You want to rewrite it, but you dare not touch it. Why risk production without a request?
It's ugly, it sucks, but it works and has always worked. I bet about half the "technical debt" I've encountered is like this, debt that will probably never be paid back. Then is it really debt at all?
The biggest reason you never have to pay back technical debt is because the company doesn't exist anymore.
The next biggest reason is because that debt no longer applies - the idea, feature, or product you wrote that code for is unnecessary and has been scrapped.
The original context of this whole "debt" conversation was startups. If you can't find product-market fit, you are dead, no matter how clean your code is. You have to move fast and iterate quickly because finding that fit is more important than clean code.
All the rules change for established companies with clear product road maps.
I would argue that yes this still is debt, because exactly as you said "you want to rewrite it, but you dare not touch it". Businesses using this software are stuck with ten-year-old processes and systems because the cost of changing the systems has become prohibitive. It's true that you'll never have to change it, but that's just because the cost-benefit of making changes is terrible from needing to wade through piles of bad code! So your debt interest payments come in the loss of business flexibility and greater support costs, and eventually in the relegation of the system to "legacy" and the cost of replacement.
But I think you're making a similar good point to the author that some debt is pretty much not actually debt. I'm sure most large systems have throwaway bits where crappy solutions are actually optimal because they are fast, cheap and don't impact core quality.
We all create it. Sometimes for better reasons than others.
It's everywhere, it's costly, and it sucks.
Then I thought about another scary truth that wasn't mentioned in either post:
Much of it never has to be paid back.
That's right, we create "technical debt", but so what?
I often maintain code that's 5 to 10 years old with as many as 100 mods. But just as often, I come across something 10 years old that looks like crap with no mods. How can this be?
Because it works. Somebody wrote a function they needed 10 years ago, and it's apparent today that they didn't know what they were doing. Since then many others have called that function. You want to rewrite it, but you dare not touch it. Why risk production without a request?
It's ugly, it sucks, but it works and has always worked. I bet about half the "technical debt" I've encountered is like this, debt that will probably never be paid back. Then is it really debt at all?