Technical Debt

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.


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.

4 Responses to Technical Debt

  1. meekrosoft says:

    You have some good points Olve, but I think I disagree with this: “The nice feature of software however is that paying back is usually both possible and comparatively cheap”. I think we have all seen legacy systems where one quick fix for production is layered upon another. These are consciously made decisions not to do the right thing- and they end up bankrupting a codebase. Once you are too far down the rat hole there is no easy way back out..

  2. Dag says:

    I agree with your general rationale over Technical debt, but you make it sound too cheap & easy. All projects will owe Technical debt, but it should be used consciusly in exceptional cases. This scared me like when I hear about people having lot of credit card debt they are unable to pay.

    You will always uncover debt that was not undertaken with open eyes, so it will be wise to have some slack for this situations too.

  3. nilshb says:

    isn’t there a conflict here with the “Don’t live with Broken Windows” ( theory? I’m afraid that once you open the tech-debt door it cannot be closed, and you will need some serious rescue packages to survive.

  4. […] not put the code into production. As Olve Maudel pointed out several years ago, however, “Technical Debt i s Good“, at least to the extent it enables earlier delivery of value to customers. The metaphor […]

%d bloggers like this: