{"id":6262,"date":"2016-02-16T06:00:04","date_gmt":"2016-02-16T14:00:04","guid":{"rendered":"http:\/\/editor.thinkapps.com\/blog\/?p=6262"},"modified":"2016-02-15T18:17:48","modified_gmt":"2016-02-16T02:17:48","slug":"technical-debt-computation-top-tools","status":"publish","type":"post","link":"https:\/\/thinkapps.com\/blog\/development\/technical-debt-computation-top-tools\/","title":{"rendered":"Technical Debt Computation: Comparison of Top Tools"},"content":{"rendered":"

This is the third\u00a0post in our\u00a0technical debt<\/a><\/span>\u00a0<\/em>series. We have\u00a0explained what technical debt is<\/a><\/span>\u00a0and explored different ways of calculating it<\/a><\/span>. Now we’ll examine tools that can assist with technical debt\u00a0computation.<\/em><\/p>\n

Introduction<\/span><\/h2>\n

In the\u00a0previous\u00a0posts, we discussed the definition\u00a0of technical debt,\u00a0its importance in any software system, and its affects on the lifecycle of a product. <\/span><\/p>\n

We also dived into some of the more technical aspects, explaining how technical debt can be expressed in man-days or currency. Finally, we briefly discovered how to calculate some important factors like test coverage and code complexity. <\/span><\/p>\n

It’s obvious that computing technical debt cannot rely\u00a0on a manual or ad-hoc process. Even if we assume that the computation of all factors affecting it can be done manually, it would take too long to get the technical debt measurement. <\/span><\/p>\n

In a practical sense, this means that, by the time\u00a0you have the numbers ready, they are already out of date because the codebase is a living object that\u00a0changes continuously. <\/span><\/p>\n

Fortunately there are some tools that can handle all of\u00a0these computations automatically and give you\u00a0nice dashboards that clearly display\u00a0the technical debt of your software. <\/span><\/p>\n

In this post, we will present three of these technical debt computation tools and explain the most useful\u00a0features offered by each.<\/span><\/h3>\n

Evaluation Criteria<\/span><\/h2>\n

There are many tools that offer code quality analysis to some extent. <\/span><\/p>\n

Some of them are focused only on particular programming languages. Others are primarily code review tools that provide automatic reviews for pull requests (via integration with popular source control management systems). There\u2019s also a third category that covers only a few of the technical debt factors.<\/span><\/p>\n

This series is about technical debt, so we filtered out any\u00a0tools that do not report directly on technical debt\u00a0(even if they calculate some of the metrics involved).<\/p>\n

We also wanted to make this post language-agnostic and thus\u00a0excluded tools that do not cover the most popular programming languages (Java, JavaScript, C++, C#, PHP,\u00a0etc.). <\/span><\/p>\n

The last criteria were ease of use and the existence of a web-interface and comprehensive dashboard that can be used by both technical and non-technical people. <\/span><\/p>\n

We were\u00a0surprised that only a few tools successfully passed our \u201ctests.\u201d We’d been hoping (deep inside) that the software industry was investing more on minimizing technical debt by creating tools to calculate it and help development teams improve their\u00a0code quality. <\/span><\/p>\n

Still, the three tools\u00a0that we present in the next sections provide\u00a0all that is needed to effectively manage and reduce your technical debt.\u00a0<\/span><\/p>\n

\"Technical<\/a><\/p>\n

SonarQube<\/span><\/h2>\n

SonarQube<\/a>\u00a0<\/span>(previously known as Sonar) <\/span>is a free,\u00a0open source code quality management ecosystem that allows developer teams to manage, track, and eventually improve the quality of their codebases. \u00a0<\/span><\/p>\n

It\u2019s a web-based application that maintains historical data and identifies\u00a0trends of leading and lagging indicators of a variety of quality metrics (including technical debt). <\/span><\/p>\n

SonarQube can be <\/span>downloaded<\/span><\/a>, installed, and run locally in less than 10 minutes. There\u2019s no need to set up a database to evaluate its features nor are any other external dependencies needed, which\u00a0provides an excellent first impression. <\/span><\/p>\n

Analyzing code<\/span><\/a> is extremely easy as the tool provides a plethora of ways to do it. <\/span><\/p>\n

If you are a Java house, simply download the plugin of your favorite build tool (e.g. Ant, Maven,\u00a0Gradle). For .NET projects, the recommended process\u00a0is to download and use the MSBuild analyzer. <\/span><\/p>\n

For projects using other programming languages (more than\u00a020 are supported via plugins), the generic runner should be used to trigger a SonarQube analysis.<\/span><\/p>\n

If you want to quickly see some screens, pages, and graphs or if you don\u2019t have the technical skills to analyze a codebase, you’re in luck. SonarQube has a public instance available<\/a><\/span>,<\/span> which contains quality data for all of the supported programming languages and the most popular open source projects.<\/span><\/p>\n

Dashboards<\/h3>\n

In SonarQube, you\u00a0can view global and project dashboards. <\/span><\/p>\n

Global dashboards are used to report information for all or a subset of the projects analyzed in the same SonarQube instance and can be presented in various ways (tree views, pie charts, histograms, or just plain lists). As the name implies, the project dashboard reports the metrics results of one particular project. <\/span><\/p>\n

What’s really cool is that you can fully customize both dashboards by adding or removing widgets of information. <\/span><\/p>\n

This means that a developer can\u00a0add several widgets displaying deep technical metrics, like complexity,\u00a0rules violations, or duplications. Non-technical managers, on the other hand, who don\u2019t need this level of granularity can create a simple dashboard with a few widgets that make sense to them. <\/span><\/p>\n

And what are these widgets? You’ve probably already guessed: technical debt widgets. <\/span><\/p>\n

Technical Debt Reports<\/span><\/h3>\n

SonarQube ships with three technical debt widgets that display important, aggregated information in a nice and comprehensive way. <\/span><\/p>\n

The first (as shown in the image below) reports the number of man-days needed to fix all problems in the code base. It also provides data about the number of issues per level of severity (from “minor” to “blocker”). <\/span><\/p>\n

Clicking on any number navigates to a page where you can see more details about the issues reported per module, package, etc. This view is called a drill-down, and it\u2019s one of the most popular pages in SonarQube.<\/span><\/p>\n

\"Technical<\/a><\/p>\n

Knowing the number of man-days you need to invest to eliminate all technical debt is helpful. But, as we discussed in the previous post, it’s not enough. Without having more context (i.e. the size of the project), it\u2019s impossible to tell if this number is good or bad. <\/span><\/p>\n

The second widget (see image below) comes to the rescue by\u00a0displaying two numbers. The one to the right is the technical debt ratio,\u00a0which represents the time needed to fix all quality issues relative to the <\/span>time that has already gone into the application development. <\/span><\/p>\n

As we explained\u00a0in the last post, this ratio fixes <\/span>the problems associated with expressing technical debt as man-days only.<\/span><\/p>\n

\"Technical<\/a><\/p>\n

In this example, the technical debt ratio is 49.8%. This means that the development team needs to spend nearly 50% more time than they have already spent to eliminate all technical debt. This\u00a0is clearly not a good result for this particular project.<\/span><\/p>\n

But what\u2019s that SQALE rating appearing to the left?\u00a0<\/span><\/p>\n

SonarQube internally uses the <\/span>SQALE methodology<\/span><\/a> to compute the technical debt ratio and to classify the project to a SQALE rating. <\/span><\/p>\n

Based on the outstanding remediation cost, the project is rated from <\/span>A<\/b> to <\/span>E <\/b>according to the following rules:<\/span><\/p>\n