What does this term mean and why should I care? "Technical debt is a concept in programming that reflects the extra development work that arises when code that is easy to implement in the short run is used instead of applying the best overall solution." (See https://www.techopedia.com/definition/27913/technical-debt). You should care because the C Suite crowd thinks the code you created ten or twenty years ago suffers from this ailment.
First Technical Debt is not fixed by refactoring. If you are refactoring your source code which means you are restructuring the code without changing how the world interacts with it, does not have anything to do with technical debt. When source code is refactored your code should be more readable and more maintainable.
Second, Technical Debt is not Technical Savings either. It is said you can accumulate Technical Savings by investing extra time with your code to make those lines of code more readable and maintainable.
What a minute here? Both of the above paragraphs are saying the same thing with different words. Is Technical Debt just technical babble? Yes, in my opinion, it is just another take on spaghetti code, GOTO's in UniBasic, nested if's, and many other reasons why old code is not good code.
Just the other day one our clients looked at a routine that was written in 1984 (Great Year!) and thought it should be re-written because of the age of the code. When this code was written years ago there was no conscious effort to implement this quickly when there might be a better solution if the code was more thought out. This code was well thought out or it would not have lasted 33 years.
A lot of companies are saying you have accumulated Technical Debt on your source code to get your to switch platforms, databases or whatever. Stop letting those people tell you what your code is or is not doing when they do not have a clue what it does.
