Technical Debt is a powerful metaphor which is used more and more often at all levels of an IT organization. The concept has been defined and strongly supported by the agile community, but it applies to all kind of developments and all types of languages. Whatever the unit you use for measuring the debt (dollars, hours, work units etc.), the figures are easy to understand and to handle.  It tells you how far you are to your coding standard compliance. This way of measuring code quality provides at least the following benefits:

• It provides an « easy to understand » and common language for all teams and their management.
• It can be easily compared with other familiar measures like delay and costs.
• It allows monitoring  trends and performing comparisons.

In addition to that you get the benefits of a « true » measure:

• It is objective. The amount of technical debt could be measured (or at least estimated) by automated analysis tools and so would not depend on subjective opinion.
• It is reproducible . Provided that you communicate your list of « what incurs Technical debt » in your context and the recipe to transform findings into the estimated value, the evaluation process is reproducible over time, over projects, over organizations.
• It is a sensitive measure, Even you are facing a huge amount of technical debt (let’s say 1,000 days) Whatever improvement you perform into your code, let’ say you spend 2 hours to refactor a too complex method, the new evaluation will be something like 999,6 days !

Because all of this, technical debt is a new measurement paradigm. When technical debt management is well implemented and deployed it becomes a powerful tool to support decisions and improve software quality.