Calculating Technical Debt

In "Quantifying the cost of expediency", I describe the problem IT management face when they trade off shorter development time with robust code. To recap, my conjecture is that a solution to understanding such trade offs can be reached by sub-dividing the problem into two phases and addressing each individually. The phases are:

1. Evaluate the code base against a set of quality criteria and track trends
   
2. Convert these metrics into an easily digestible form

At the AgileNM meeting today, I learned there is a term for the code degradation that often occurs in a software project: technical debt. We had an excellent discussion of qualitative ways attendees assess this cost. These included:

• Decreases in team velocity over time
• Developer time to understand unfamiliar code
• Querying developers

How exciting to have this group interested in the very topic I've been pondering and writing about! In looking for quantitative measures of technical debt, my research turned up several candidates for calculating the current debt and tracking trends. This list is shamelessly lifted from the Sonar Related Tools page:

Open Source

• Sonar
• Maven Dashboard Report Plugin
• QALab
• XRadar

Commercial

• CAST Software
• SC Metrics from MetrixWare
• McCabe IQ

The commercial tools don't appear to have evaluation downloads, so I'll focus on open source tools for now. Perhaps I can get evaluation copies in the future.

The open-source tools all leverage other open-source tools that determine one or more pieces of the technical-debt picture. Checkstyle, PMD and CPD are static analysis tools while JUnit and Cobertura are runtime tools which all contribute to understanding the debt .

The open-source tools are all Java-centric. I'll search for similar .Net tools.

Originally, I had planned to jump into Sonar but, given the alternatives, it seemed prudent to consider what features best support calculating technical debt. I haven't looked at any of them closely yet, so hopefully this list isn't overly biased:

• Plugin architecture for adding new analysis tools
  
• Flexible rules for rolling up results into characteristics
• Current and trend perspectives
• Support for multiple languages and environments
• Able to consider qualitative data in calculating characteristics
• Support for multiple build tools
• Flexible dashboard creation to display results
• Interfaces to continuous integration servers
• Vigorous user community
  

In the next installment I'll present my take on how the open source tools stack up against this feature set.