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.
This is a really silly point to write, and obviously disprovable. Here's a really simple and realistic example:
You've just deployed your app. It's perfect... except there's this huge performance issue with one of the most important pages. Your app's just gone up on Slashdot, TechCrunch, and everywhere else. Zillions of people are using it. You have two options:
1) An ugly evil hack that will sort out the performance for that page. Total time: 30 minutes.
2) A re-architecting of that part of the application that will cleanly resolve the performance problem with efficient use of caching. Total time: a week.
If you choose option 2, you're a moron (sorry, no other way to put it). Option 1 obviously increases your net worth. Yes, you need to go back and do 2) as well, but this is a pretty damn good scenario where it makes a lot of sense to write and ship bad code knowingly. And yes, it does increase your net worth - those zillions of users might stick around instead of claiming your app's broken and moving on.
Your first sentence sums it up nicely. Speaking as someone whose family has been kept fed by the "agile" gravy train, let me say first that I think all that stuff is valuable. However, many of the industry gurus make these broad, sweeping generalizations based on their own experiences, and most of their experiences come from consulting work for huge, broken corporations. Applying these lessons to startups, or to small, fast companies in general, is just nonsense.
What is this talk of 'release'? Klingons do not make software 'releases'.
Our software 'escapes' leaving a bloody trail of designers and
quality assurance people in its wake.
Heh, this always gets me to laugh. I've been on both sides of this issue though: I worked at a place that shipped code and their version 3 release is shaping up to be what their 1.5 release should have been. But I can also get to the point of paranoia, "I can't release this! it still has bugs!"
Maybe we just need to have a "release determination board" filled with 50% pessimists and 50% optimists. That way, you'd have a huge argument over when to release.
To release is risk, but is risk itself imprudent? I doubt it.
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?