With borrowed money you can do something sooner than you might otherwise. If you are willing to incur technical debt you can release a product earlier than you might otherwise.

We all recognize these stereotypes: The sales team is willing to (and sometimes do) sell a product and cash in the money long before development is finished. While the engineers are reluctant to let go of their baby because there are always things that can be improved. A successful business needs engineers and salespeople that are willing to compromise and cooperate on this conflict of interest. Technical debt is a powerful metaphor that can be used to work on a compromise, especially when we are talking about software development.

Technical debt in a software project includes internal things that you choose not to do now, but will impede future development if left undone [1]. Examples of technical debt might be: We need to upgrade our compiler to a more recent version, but let us ship the product now and upgrade the compiler later. We do not properly understand how to implement this feature properly anyway, but this hack seems to make the customer happy for now. We have identified some dirty code that is slowing us down, but we choose to fix it in the next release instead. These are all examples of prudent and deliberate reasons [2] for taking on technical debt which can be compared to borrowing money for sensible housing. There are also less responsible ways of incurring technical debt though, perhaps caused by; lust, gluttony, greed, sloth, wrath, envy or pride. Examples might include: writing bad code, skipping analysis and design, over-engineering, résumé-driven development and so on. This kind of technical debt is more like unauthorized overdrafts and check bouncing, and is best avoided if you have a long-term vision for your product.

Like financial debt, a technical loan will incur interests, and if you are not able or willing to pay back the loan then you risk go into bankruptcy. The nice feature of software however is that paying back is usually both possible and comparatively cheap. While making effective and strategic decisions about what internal qualities to postpone you should keep track of them and write down an estimated effort needed to do it properly. This will give you an idea of how much you owe at any point in time. Then, after rushing a release out of the door, you can immediately start to pay back by doing the postponed things properly and get a flying start into the next release. Retrofitting stuff like this might appear to be more expensive than “doing it right the first time”, but since we are dealing with software it is often the right approach.

Perhaps the most powerful feature of the Technical Debt metaphor is that it communicates well between technical and non-technical people [3]. By quantifying the current technical debt in your product it should be possible to get management both interested and involved in the importance of controlling the debt burden.

References:
[1] www.c2.com
[2] martinfowler.com
[3] blogs.construx.com/blogs/stevemcc

UPDATE June 2010: At Smidig 2009 and XP2010 I presented a talk titled “Technical Debt is Good!” based on this material. Here are the slides (pdf) that I used in norwegian and english respectively.