Skip to main content
All CollectionsReference
Technical debt analysis
Technical debt analysis

This article summarizes what analysis capabilities can be used for monitoring technical debt of software

Ville Laitila avatar
Written by Ville Laitila
Updated over 5 years ago

Explicit and implicit technical debt

There are several ways how developers place hints on the technical debt:

  • Adding comment to the source code that describes the issue (usually a TODO)

  • Using TODO etc. keywords in Git commit description/message

  • Hardcoding TODO or similar content into code as string variable values instead of returning the correct value

  • Raising a special kind of exception

In addition to these explicit ways of describing technical debt, there is more obscure ways, such as leaving something clearly unimplemented, visibly blank.

Certain kinds of technical debt are more difficult to discover: e.g. spaghetti code, dependency hell, suboptimal performance or misunderstood requirements.

Methods on analyzing technical debt in Softagram

Softagram supports detecting explicit technical debt with these approaches:

  • Special tech debt code comments are detected in the continuous analysis. Softagram looks usage of the following words in comments: TODO, HACK, FIXME, OPTIMIZE, XXX, BUG, TBD and WORKAROUND. Code lines with any of these words are classified as technical debt markers in Softagram and calculated into a metric so that the amount is easily trackable. Softagram marks up addition and removal of these lines to make it easy to monitor changes of technical debt. Some teams are having the habit of checking the delta and the current amount in every sprint review meeting.

  • Using TODO etc. keywords in Git commit messages is not currently detected in Softagram. Instead, Softagram has currently bug_fix_ratio which shows how many of the commit descriptions have bug, fix or hack keywords. While, it is not purely about technical debt, raising bug_fix_ratio in some code file shows that there has been recently many quality issues that has assumably been fixed recently. 

  • Hardcoded string values that refer to the special words (TODO, etc) are detected as technical debt markers and added up to the tech_debt_marker_count similarly as code comments.

  • Raising special kind of exception such as NotImplementedException is not currently covered.

The dependency analysis of Softagram is ideal for assessing the technical debt of unclean dependency network. Having too many dependencies or cyclical dependencies is made visible in dependency visualizations. Sometimes this is seen in pull request comments created by Softagram, as every pull request gets feedback from Softagram in form of a dependency visualization if the pull request changes add new dependencies to the software. Softagram Desktop also has special capabilities to visualizing dependencies between directories, files, classes and functions, and also to identifying cyclical dependencies (proposing dependency changes in current view).

Unwillingness of creating new code files (when adding new functionality) is an indicator of technical debt where the complexity has been grown all over the usual limits. This sort of situation can be detected by inspecting the trend of average file LOC metric.

Ways of representing technical debt: heatmaps

Heatmap visualization provided in Softagram Desktop: (generic heatmap visualization renders the code elements such as directories with heatmap coloring of the selected metric, in this example it is for tech_debt_markers_count

Did this answer your question?