Reducing Technical Debt and how to go about it was a hot discussion with one of our clients recently. First we discussed the metaphor and how the debt metaphor really fits for software projects as well as other domains. The metaphor created by Ward Cunningham back in 1992 was meant to help explain to non-technical stakeholders that there was a cost to not doing things the right way; that doing things the fastest way, may have costs later on. But as in the financial domain, debt is not always bad. Sometimes we want to have something now and pay back later. That's the concept of principal and interest. The question is how much is the principal and interest and will the interest bury me in the long run? Just like financial debt which can be a silent killer and can either cause problems or hide problems, technical debt has the same ramifications:
- Tasks that are not done but run the risk of causing future problems if not completed.
- Aspects of the software that have been done incorrectly (usually quicker or easier), but there is no time to do it right (now), or fix it.
In reducing technical debt, first we