Usability - Productivity - Business - The web - Singapore & Twins

Technical Debt

One of the publications that gives you a good overview what is happening in the world of software development is SD Times. Their parent company BZ Media conducts physical and virtual events. Todays invitation rose my interest since it was titled " A Technical Debt Roadmap". From the description:
" "Technical Debt" refers to delayed technical work that is incurred when technical short cuts are taken, usually in pursuit of calendar-driven software schedules.
Technical debt is inherently neither good nor bad: Just like financial debt, some technical debts can serve valuable business purposes. Other technical debts are simply counterproductive. However, just as with the financial kind, it's important to know what you're getting into.
Go sign up, the speaker is Steve McConnell, the author of Code Complete . Having grown up in conservative Germany (yes I'm Bavarian) the concept of "Schulden haben" (having debt) had the stigma of failure and loose morals and I'm very concerned when looking at the required interest payments when it comes to debt. A very German engineering trait is that "things need to be done right" rather than "good enough". It is the foundation of successes like Daimler, Audi or BMW. In a nutshell it is the idea that on delivery a piece of work must be debt free. This doesn't translate very well into software, which by the nature of facts can't be debt free. So it is always a balancing act. Ever increasing complexity and growing interdependency seem to favour greater amounts of debt: "Delivery is now, the fixpack is later". However there are different kinds of debt, like in the financial world: your mortgage (hopefully) backed by an asset, your consumption loan, your credit card balance and (hopefully not) that open item from the loan shark in the casino. The equivalent in software would be (in no particular order):
  • Hardcode debt: system names, maintenance passwords, URL settings etc. are fixed values in an application. Debt is due if any of these needs to be changed. Typically can be found in organisations where creation and maintenance of applications are strictly separated or the development team lacks the experience
  • Broken code debt (the classical bug): something doesn't work as expected. Usually gets paid once the bug surfaces and a big enough customer complaints
  • Missing feature debt: Gets paid in a following version - if there is one
  • Missed expectation debt: Sales, marketing or management make promises or announcement that don't get realised in the current code stream. Close relative to the "missing feature debt". Typically that debt is met with product management denial: "How much more do I sell if I implement that?" Denial since the one who created the expectation already "spent the money" and failure to service this debt will lead to loss of repudiation, credibility, trust and ultimately customers and revenue
  • Non-Functional debt: Software does what it should but misses non-functional requirements like robustness (against failure) or resillience (against attack) or integration capabilities. Expensive debt (it would call it the credit card balance of software) since the discovery of resillience flaws often leads to (expensive) emergency actions and the lack of integration capabilities leads to rewrites or addition of a lot of middleware. Also it is difficult to spot since more and more software is business funded where there is little understanding for non-functional traps
  • Bad code debt: The equivalent of a loan shark arrangement. Looks OK on first view, the software works at delivery (the night in the casino wasn't disrupted by lack of funds). Usually payment is limited to parts of the interest (patch it up baby). Leads to abandoning of systems (declared bankruptcy). Typically that debt is hidden as long as possible (who wants to admit to owe to a loan shark) to then take everybody "by surprise".
Paying technical debt requires real money. It is paid back with engineering hours someone needs to pay (if you can find the right talent). As with all debt: if you only serve the interest but not the principal the debt doesn't go away and at some point the interest payments will be more than the principal. Something a myopic quarter to quarter view might overlook.

Posted by on 28 December 2010 | Comments (2) | categories: Software


  1. posted by Tim Tripcony on Wednesday 29 December 2010 AD:
    I absolutely love this analogy. The converse of debt is investment: in order to avoid accumulating debt in the first place (or, even better, make investments that will continue to accumulate rewards over time), I must be willing to "save up" for what I want, to take the time up front to do it right the first time, even if that means waiting a couple months longer than I'd hoped to produce the bright, shiny object I (or my customers) want. The benefit of this can often be very difficult, in our profession, to convince management of while there's still time to avoid making "impulse purchases", but doing so is crucial to their success, even if they're unwilling to believe that.
  2. posted by Nathan T. Freeman on Thursday 30 December 2010 AD:
    I've been thinking about this for a couple of days now, and there's some stuff missing...

    Deprecation debt - The equivalent of an asset that's fully depreciated (never noticed those terms have the same root until right now) and is still relied upon even though it's officially outdated from an accounting perspective.

    Unmaintained debt - debt that could be refinanced with a small effort to dramatically reduce the interest rate.