Technical debt is a metaphor coined by Ward Cunningham in 1992. This concept refers to the work that needs to be done so that a software development project could be considered as “complete”. Could you try to measure your amount of technical debt? Could you use some tools to do this? These are some of the questions that this article explores.
In a brief informal survey of Agile practitioners, the idea of putting some number on the amount of technical debt was mostly considered as strange. Somebody even answered that if you had a good definition of “done”, your project should never create any technical debt. For those who live in a less perfect world, technical debt could be created in all the software development activities: architecture, design, coding, testing and configuration management. You don’t have to be an evil programmer to create some debt, especially in large projects. You just duplicate some code because you don’t know that the same feature is also implemented elsewhere in the system or you rely mostly on manual testing to verify an urgent change needed for a bug in production. Sometimes, it is the requirements or the concept that changes and you should refactor some to make variables names more meaningful.
Tools to detect some of the technical debt issues have existed for a long time. There are plenty of them available for code analysis or test coverage. Some might provide “absolute” information, like the violation of a coding standard, and other will just produce “smells” that needed to be manually examined. In any cases, you should not expect a solution that will compute a precise number… even if some companies have done this. Each project has its own context and each software team and developers have their own view on what is acceptable. Multiple reports from these tools will however provide you with a trend. You might for instance wonder if your continual decrease in test coverage might be caused by trying to produce in each iteration an amount of code larger than what your testing resources might examine?
The global tools
The main principle behind the global tools is to provide a dashboard to software development managers so that they can assess the quality of their codebase. This is done mainly by aggregating the data produced by internal or external existing tools that provides a specific type of information. If these global tools can provide an interesting overview of the situation of your codebase, their users notice that you need a certain amount of investment to make them running according to your rules.
Bliss is a technical debt dashboard that focuses mainly on the coding and testing aspects of software development. Bliss measures technical debt as an accumulation of flags reported by various static analyzers, mainly open source, that run against your code base hosted on GitHub or Bitbucket. Bliss can provides some reports on the source of technical debt, its evolution and how each developer is contributing to it.
Web site: https://founderbliss.com/
CAST Application Intelligence Platform
CAST Application Intelligence Platform (AIP) is defined as “an enterprise-grade software quality analysis and measurement solution designed to analyze multi-tiered, multi-technology applications for technical vulnerabilities and adherence to architectural and coding standards.” AIP is a commercial tool available in SaaS mode or on premises. It aims to provide a bottom-up view of technical debt but has also many other features like benchmarking. This tool relies on some other CAST proprietary tools to perform its analysis
Vendor: CAST Software
Web site: http://www.castsoftware.com/
SonarQube, or “the software previously known as Sonar”, is an open source platform that provides a dashboard to visualize the quality attributes of your code, tests, design and architecture. Built originally with Java in mind, the platform covers now more than 20 programming languages. The basic version of SonarQube and many plugins are open source but there are also some enterprise commercial solutions for larger teams or for some specific technical contexts.
Web site: http://www.sonarqube.org/
Teamscale is a commercial tool that aims to makes software quality visible and empowers software development managers to take action against software quality decay. Teamscale points to quality defects that are easily missed: clone detection reveals redundancy in your code, architecture conformance analysis detects unwanted dependencies, bug pattern search finds potential programming errors. It works with many languages and version control systems. Teamscale provides plugins to manage quality in both Eclipse and Visual Studio.
Web site: https://www.cqse.eu/en/products/teamscale/landing/
In a future part of this article, we are going to present some tools that can be used to assess the technical debt in specific software development activities: architecture, design, coding and testing.
Managing Software Debt: Building for Inevitable Change, Chris Sterling, Addison-Wesley