I must confess it: I have always been wary of the concept of technical debt. It has always seemed a marketing concept to me.

It’s like if you decided to buy a car, and the salesman will be giving you the keys and proudly adds with a smile: “you owe already $ 10 000”. And he does not speak about the car credit, no, he simply means that the car you have just bought contains certain flaws that will become increasingly apparent over time, and weary the engine, the body, even probably the driver.

How would you react if a salesman told you that? Would you buy this car?

Okay, I know that purchasing a car, a house, anything expensive and complex to produce comes along with costs of maintenance. In this sense, I like the explanatory power of the technical debt analogy and besides, software development has often been compared to the construction of a house.

But everybody knows the story: when Ward Cunningham invented the concept in 1992, it went relatively unnoticed, at least outside of the developer community, until recent years when, Bang, technical debt becomes a media explosion and really, it frightens. According to Gartner, it has reached $ 500 billion in 2010 and is expected to double by 2015. With such an inflation, it will be higher than the sovereign debt of Russia in 2020. I feel really anxious.

Technical Debt is a marketing guy’s dream because:

• It is technical, thus it is convincing, and the one who speaks about it looks like an expert. A good marketing guy first goes for himself’s marketing.
• It draws the attention: you owe money – many – and you did not know.
• It allows all sorts of very creative exercises: ceiling of the debt, calculation of the interests, break-even point estimation, reduction of the systematic risk, etc. Very creative: the notion of toxic code or toxic application. I wonder if they supply the gas mask to developers.

As explained by Ward Cunningham (Ward Explains Debt Metaphor), he used the metaphor of Technical Debt to justify to his boss the refactoring done on the financial software they were developing. By borrowing at the beginning, it is possible to go faster, but you must then pay the interest. As in expanding your business: if you can borrow, you can hire more people, invest in more outlets, have an advertising budget, etc.. You will grow faster but you cannot borrow continuously because otherwise the interest and repayment of your debt will eventually become your main expense and prevent any growth.

Ward also explains that his comments were resumed confusely, not to say erroneously. He insists on the fact that a code must be correctly written from the beginning to allow then refactoring. Borrowing does not mean writing code of mediocre quality to bring out quickly the application in due course in spite of the delays of the project or the errors of schedule, if not develop quickly frequent versions (Extreme Programming) and install refactoring in the lifecycle of the project.

Ward Cunnigham is a developer who, as he explains it himself, used the concept of technical debt as a metaphor. There are 2 types of metaphors:

• Those with descriptive power, to understand a concept by illustration, by comparison with another concept.
• Those with predictive power to predict a certain behavior or to discover new laws.

For example, you are asked to explain what is an atom. You can make an analogy with a planet orbiting its sun, like electrons around their nucleus. It would be an analogy of the first type.

Now if you decide to build a model of a solar system as a set of objects (planet, sun), attributes (mass) and relationships (attraction), and if you use it to derive a new model between electrons and their nucleus that allows to predict their behavior, then it will be an analogy of the second type.

The metaphor of Ward Cunningham is a very powerful explanatory tool, but it’s not a model from which to draw new laws. His main interest lies in the idea of ​​incorporating the refactoring in the lifecycle of an application. To pretend that it is possible to quantify the technical debt, calculate its cost relatively to the line of code, to assess interest on that debt, to estimate where in its curve it becomes too heavy, it’s Marketing.

Moreover, it is not innocent if the figures are usually scary and growing from one year to another. Why do you think your application of 300,000 lines of code presents a technical debt of $ 1 million even before anyone looks at it and see what really is its level of non-quality? How much would you willing to spend to reduce this debt without doing any analysis? $ 100 000? $ 200 000?

The developers have understood it well. Technical debt is:

• The idea that code refactoring should be done on a regular basis to limit non-quality at an acceptable level.
• An interesting indicator that introduces a concept of effort and cost of correction.

If you have the choice between correcting a critical flaw for a very low cost and correcting a defect of little importance for a high cost, you will obviously not hesitate for long.
As such, technical debt can be a tool for decision support, but never forget that this is not a real financial cost and know how to interpret it correctly. Some examples.

You can use technical debt as a technical indicator in an SLA for a provider, but in different ways depending on the nature of project:

• New development: a zero technical debt does not make sense, any new application even very well written will necessarily involve a minimum of very large or complex components or with many links between them. Simply ensure that their numbers remain reasonable. So define with your supplier a level of technical debt that he must not exceed.
• Maintenance: your provider is not responsible of the technical debt on an existing application developed by someone else. He must only prevent it from becoming more important. Here, no question of a threshold of technical debt not to be crossed but rather of avoiding its growth. You can even encourage your supplier to decrease it with bonuses.

Align your technical debt on your IT goals, self-aligned with business objectives. We have already seen in the post ‘Best of both world‘ that a zero tolerance policy for defects of performance does not make sense when the most important is to not exceed budgets. Conversely, if money is not a problem but the application must work properly in a timely manner, the violations of performance and robustness and time-to-market become critical. Build your action plans based on objectives, and then only in terms of critical debt, not the reverse.

Leave enough space for project teams to decide for themselves the actions of refactoring, but set with them a target about technical debt and include it in a Quality Gate. Generally, developers will be effective in that they optimize their refactoring actions by correcting the most serious flaws that are less costly. However, this assumes that they are equipped to assess the technical debt with a code analysis tool. About this see our post ‘10 to 20 metrics’.

These are just a few simple examples, based on our previous posts. There are many other ones, and perhaps we will have the opportunity to detail them in the future.

Technical Debt is an interesting measure that allows objective data to improve the relationship with suppliers and project teams. It is an indicator of an order of magnitude in terms of effort to maintain the non-quality at a reasonable level.

But do not consider technical debt as a real financial cost to evaluate your decisions and project investment. It is a developer’s concept developer for developers, not for marketing guys.

This post is also available in Leer este articulo en castellano and Lire cet article en français.