Wednesday, 15 January 2014

Re-purposing the Technical Debt Metaphor

Recently, I had cause to re-visit the ‘Technical Debt’ metaphor coined by Ward  Cunningham when referring to agile software development:

I am finding, however, it applies to a much broader set of circumstances such as: unmanaged introduction of Consumer-grade I.T., Line-of-Business ‘Credit -Card-Cloud’ consumption and 'technology-solution-without-a-requirement-and/or-architecture’ implementations. So I’ve had a go a rewriting Ward’s original words:-

“Technical debt is a metaphor an incremental, get-something-started approach with the easy acquisition of money through fast loans.

A monetary loan, of course, has to be paid back with interest. In terms of software development & technology selection &  deployment, payback requires the technicians to re-work the solution as they learn more about how it interacts with other technologies and which features are being used, or not, or are now needed. Just as monetary debt can easily spiral out of control if not managed properly, so can technical debt.

In business, the metaphor is often used to illustrate the concept that an organization will end up spending more in the future by not having sufficient understanding the complete requirements before selecting a solution. The assumption is that if an organization chooses to ignore a course of action it knows should be taken, the organization will risk paying for it in terms of time, money or damage to the organization's reputation in the future. As time goes by, efforts to go back and address the missing requirements may become more complicated and, otherwise, messy. Eventually the problem may reach a tipping point and the organization must then decide whether or not to honour its original debt and continue investing time and effort to fix the problem. This decision can be made more difficult by something called ‘the sunk cost effect’, which is the emotional tendency of humans to want to continue investing in something that clearly isn't working (e.g. can’t scale or missing features)”.

Anything you’d add/change/delete?


  1. I now deliberately avoid using the term 'debt' as I think that we have stretched the metaphor too far. Technical debt is impossible to measure, unlike monetary debt. And because it cannot be measured, it cannot be repaid, borrowed against, nor effectively communicated to non-technical stakeholders.

    I think we need a new term - but cannot (yet) offer a suitable replacement.

    1. Thanks for the comment. Let me know if you come up with a better one :)