Why managers like the Technical Debt concept

Since its introduction by Ward Cunningham, the concept of technical debt is quite well recognized and used more and more by project managers to monitor their project.

What is quite surprising (and also beneficial) is the fact that this quite technical concept is also used and supported by middle and upper managers. I have already mentioned within a previous post that the CIO of a very large bank (30,000 + developers) monitors on a quarterly basis, and with the SQALE method, the technical debt of its complete portfolio.

There are probably many reasons for this growing interest and each manager will have his own. Here are the reasons, which in my opinion, are the most common.

  1. Technical debt is an objective measure of quality. In fact it measures “non-quality” and tells you how far (in terms of days, $…) you are from complying with your “right code” definition. This is a very simple concept. It is easy to understand and facilitates communication.
  2. Consolidation is easy: Consolidation is performed by simple summation. If you have an estimation of the technical debt of each of your applications, then it is easy to get the technical debt for each of your domains and for your complete portfolio.  As an example, this is what is automatically performed by the combination of the views and SQALE plugin of the Sonar platform. If your static analysis does not do it for you, it’s still easy to consolidate the numbers within Excel.
  3. Technical debt density has a useful meaning. It’s easy to calculate the technical debt density of an application or a domain etc. You just need to divide the technical debt of an item by its size (If your analysis tool does not support this feature, again, Excel will do it for you). This will allow you to compare quality of items of different size. You will be able to compare projects developed (or maintained) by different subcontractors or in different locations.
  4. Technical debt is estimated in days or dollars, which can easily be compared with other project or portfolio management data. It is meaningful to compare technical debt to other measures like remaining schedule or budget allocated on a project. Technical debt can be correlated to such project data (and many others) providing support to managerial decisions.

Technical debt is probably the first code related measure which fulfills the measurement needs of managers; it also fits well into their favorite tool: Excel. Their interest for this measure is not a temporary fashion. Technical debt is becoming part of many management dashboards and will support more and more portfolio management decisions.

Your strategic decisions will depend on the precision of your Technical Debt estimations. Make sure that your estimation model is calibrated to your context.