Technical Debt: A get out of jail free card, courtesy of Ward Cunningham, for delivering nothing for a while, yet keeping your job. Throughout which one may also actually fix some technical issues of a system.
Second, how come you accumulate technical debt? There are various reasons (justifications?) around for creating technical debt like Martin Fowler's 'quick to do but is messy' way of adding functionality to a system rather than a 'cleaner design'.
This is the way I see it. You need to add a piece of functionality to a system. The system is nice abstraction, nicely flowing. Either;
- you are new to the system, there is nobody left to ask, not much time to properly understand, you just shoehorn some code that barely makes it do what you want it to do.
- or the system is built on some axiom (like it only works for luner rovers, little gravity, not any level of gravity but you need it to work on venus) but you still go ahead and hack it in.
- or the system was build by chimp child programmers so it is a technical default that needs an Angela Merkel style austerity plan.
This is the trick; you need a plan! Paying off Technical Debt must mean actually fixing the system.
Have a plan; This is where the system is now -> this is where I want it to be when it is all over. Correct the abstractions, re-aligning the axioms to reflect the current design at hand, remove unnecessary complexity. *
Once someone described me a technical debt effort to me once as: 'They are adding a cache here, a lock there, trying to mend the thing but most of that software needs a good re-work' Adding a cache here, a lock there is not paying your technical debt, it is force programming. That creates, guess what, more of the same.
Don't force program.
* Quick disclaimer: I do not mean future proof a design or create a 'save the software industry' framework. I am talking about a proper think through the issue in hand at the moment.