An alternative interpretation is that technical debt depreciates. That is, in a Darwinian way, clearly the product survived WITHOUT implementing the changes someone thought it needed. So is it really technical debt, or just baggage?
Sometimes, debts are written down.
Whether it is "baggage" or "debt" depends on whether it is accumulating interest (that is, it makes other changes such as adding features harder and harder to do).
But if your service is large enough, a maintenance window costs you money, reputation, customer satisfaction and makes you breach contracts and service level agreements... you may want to find ways to minimize maintenance downtime.
In that case you will want to make your code straightforward enough so mean time to detection and mean time to repair is low by emphasizing maintainability, namely, clean code with accompanying tests.
...and this is one reason that many business die, the assumption that past performance is indicative of future results.
The reality is that you are making a bet with unlimited downside (e.g. a naked call in stock parlance) when you don't address technical debt.
"Sometimes, debts are written down."
One word: Enron.
Then, there needs to be awareness and a sense of urgency. Technical debt accrues interest.
In my case, I use deprecation tags:
- @deprecated on javadoc for Java (http://download.java.net/java/jdk9/docs/api/java/lang/Deprec...), JSDoc for JavaScript (http://usejsdoc.org/tags-deprecated.html), Yard for Ruby (http://www.rubydoc.info/gems/yard/file/docs/Tags.md#deprecat...)
- Obsolete attribute on .NET (https://msdn.microsoft.com/en-us/library/22kk2b44(v=vs.90).a...)
- deprecated pragmas and macros in C++
- DeprecationWarning on Python (https://docs.python.org/3/library/warnings.html#warnings.war...)
By doing this:
- You get a deprecation warning.
- Some editors may highlight it.
This signals people to stop using that code.
This creates a sense of urgency to switch to or create a refactored alternative that is cleaner.