Tools to Manage Technical Debt

A visualization from Squore showing software quality. Source: Vector Informatik 2020.
A visualization from Squore showing software quality. Source: Vector Informatik 2020.

In an ideal world, developers follow best practices and implement the best possible solution. In practice, this is rarely the case. Technical debt is often accepted to satisfy immediate business needs. However, this debt must be managed in the long term. Except for the most trivial projects, it's difficult to manage technical debt through manual effort. Fortunately, many tools exist for this purpose.

Engineering systems are diverse because of their choice of hardware, software programming language, development methodology, system architecture, test plan, and so on. As a result, technical debt is also rich in variety: architecture to code, documentation to testing. Tools to address them are also varied. A project might need to adopt more than one tool to manage its technical debt.

Discussion

  • What features are expected of tools that manage technical debt?

    Good technical debt management tools are expected to have these traits:

    • Polyglot: Tools need to analyze the source code. As such, they must support popular programming languages (Java, JavaScript, C/C++, C#, Python, PHP, etc.). This support could be offered as plugins to the main product.
    • Analysis: Analysis must be from different perspectives including maintainability, reliability, portability and efficiency. Approaches can include static code analysis, SCM analysis, and test coverage. Tool should record historical data so that trends can be observed. Tool should show time needed to fix the debts.
    • Reporting: Dashboard should show a high-level summary and project status. Dashboard should be customizable since engineers and business folks are interested in different levels of detail. Visualizations should be clear.
    • Deployment: The tool can be hosted on-premise or in the cloud. For multiuser access, it should be a web application.
    • Flexibility: It should be possible to override default values and configure the tool to suit the project. For example, thresholds to detect duplicated code must be configurable.
    • Logging: We may wish to get insights into the analysis or troubleshoot issues. Tool should therefore collect logs for future study or audit.
  • Could you mention some tools to manage technical debt?
    Feature support of some technical debt tools. Source: Pavlič and Hliš 2019, table 2.
    Feature support of some technical debt tools. Source: Pavlič and Hliš 2019, table 2.

    Some tools only report code metrics, facilitate code reviews or support only a few languages. Others support multiple languages, cover multiple debt factors, perform risk analysis, visualize debt in different ways, and offer a useful dashboard summary. Among the latter are SonarQube, Squore, and Kiuwan.

    Bliss, SonarQube, Checkstyle, and Closure Compiler are some tools that help with static code analysis. Designite can detect design smells, such as a class doing things that are not part of its core responsibility (poor cohesion). Jira Software and Hansoft are examples that identify but don't measure technical debt. Jacoco captures test debt.

    Among other tools are CAST Application Intelligence Platform, Teamscale, SIG Software Analysis Toolkit, Google CodePro Analytix, Eclipse Metrics, Rational AppScan, CodeXpert, Redmine, Ndepend (Visual Studio plugin), DebtFlag (Eclipse plugin), CLIO, CodeVizard, and FindBugs.

    In general, there are more tools for code/test debts than for design/architecture debts.

  • How do tools quantify technical debt?
    A cost model for calculating technical debt. Source: Parthiban 2019, table XXXIV.
    A cost model for calculating technical debt. Source: Parthiban 2019, table XXXIV.

    Tools should show metrics that are simple, clear, correct and objective. They should help in decision making. There are many metrics to quantify debt with respect to design, coding, defects, testing, documentation, and other aspects of product development. Tools should therefore measure code duplication, code complexity, test coverage, dependency cycles and coupling, lack of documentation, programming rules violations, and more.

    Ideally, a few numbers that express overall product quality will be easier to understand at a high level. Expressing technical debt as in units of person-days points to the effort needed to remove the debt. This is a good measure but it doesn't indicate product quality. Therefore, we can also express technical debt as a ratio. Generally, debt that's higher than 10% needs to be addressed quickly.

    Tool should also capture trends. For example, a declining trend in test coverage might suggest that with each iteration the team is adding more features that it's capable of testing.

    In general, effort estimates are hard to get right. The suggested approach is to remove technical debt gradually (pay off the principal) with every release.

  • What are some approaches that tools use to manage technical debt?
    Conceptual model of technical debt to aid debt quantification. Source: Nord 2016.
    Conceptual model of technical debt to aid debt quantification. Source: Nord 2016.

    Given various aspects of managing technical debt, we note the following approaches:

    • Identify: Code analysis, dependency analysis, checklists; compare against an optimal solution.
    • Measure: Use mathematical models, source code metrics, manual estimation by experts; estimate based on debt type; use operational metrics; compare against an optimal solution.
    • Prioritize: Cost-benefit analysis; repay items with high remediation cost or interest payments; select a set of items that maximize returns (portfolio approach).
    • Monitor: Warn when thresholds are reached; track debt dependencies; regular measurements; monitor with respect to defined quality attributes; plot and visualize trends.
    • Document: Record each item in detail with identifier, type, description, principal and interest estimates; probability of interest payment; correlation with other items.
    • Communicate: Summarize in dashboards; record in backlog and schedule with each development cycle; list or visualize items.
    • Prevent: Improve processes; evaluate potential debts during architecture/design phases; create a culture that minimizes debt.
    • Repay: Refactor, rewrite, reengineer (new features); automate routine tasks; fix bugs; improve fault tolerance in areas of debt.
  • What are some shortcomings of tools that manage technical debt?

    Tools may differ in the way they quantify technical debt. The calculated metrics may be incomplete or even inaccurate. For example, a tool may fail to capture architectural debt, such as when code violates layered architecture.

    There's no clear consensus on the dimensions or boundaries of technical debt. For example, some may consider known defects as technical debt. When tools report false positives, dealing with these can be tedious.

    Many tools calculate the principal (cost of refactoring) but not the interest (extra cost due to technical debt). The latter is more difficult to quantify. However, it should be noted that the SQALE method has models to estimate both remediation cost (principal) and non-remediation cost (interest).

Milestones

1992

Ward Cunningham coins the term Technical Debt while working on WyCASH+, a financial software written in Smalltalk.

2001

The Agile Manifesto is signed. In the following years, the concept of technical debt is more widely adopted with the growth of the Agile movement.

Feb
2007

The first lines of code are written for the Sonar platform. In November 2008, SonarSource is founded to accelerate development and adoption of the open source Sonar platform. By mid-2010, SonarSource gets regular downloads. In April 2013, SonarSource gets a commercial edition and is renamed to SonarQube.

Sep
2009
SQALE calculation of indices from remediation cost table. Source: Letouzey and Coq 2010, fig. 7.
SQALE calculation of indices from remediation cost table. Source: Letouzey and Coq 2010, fig. 7.

In a white paper, Letouzey and Coq introduce the SQALE (Software Quality Assessment Based on Lifecycle Expectations) Analysis Model. They note that in qualimetry, any measure of software quality should be precise, objective and sensitive. The SQALE model provides normalized measures and aggregated indices. Since software is a hierarchy of artefacts, the model standardizes aggregation rules that lead to remediation indices. Since SQALE is open source and royalty free, by 2016, it's implemented by many tools.

2014

Multiple studies are published in literature that attempt to understand technical debt and relate it to software quality. A couple of these studies use SonarQube and its plugins for analysis.

Mar
2015
Feature comparison of some technical debt management tools. Source: Li et al. 2015, table 16.
Feature comparison of some technical debt management tools. Source: Li et al. 2015, table 16.

Li et al. bring together different studies and summarize the capabilities of 29 different technical debt management tools. They map them to various attributes: identification, measurement, prioritization, monitoring, repayment, documentation, communication and prevention. Most are able to identify or measure technical debt. In addition, they capture what sort of technical debts these tools capture: code, design (code smells or violations), testing, requirements, architecture, and documentation.

Apr
2015
Jira allows tracking of technical debt items. Source: Radigan 2015.
Jira allows tracking of technical debt items. Source: Radigan 2015.

In a blog post, Atlassian recognizes the importance of technical debt. The note that their Jira software can now list and track technical debt, including when a debt was created and when it's expected to be resolved.

Nov
2018

DeepSource is released. It's a source code analysis tool that can integrate with GitHub. Test coverage, documentation debt, security, and dependency debt are some things it can capture.

Oct
2019
A refactoring suggestion in SonarQube. Source: Oswal 2019, fig. 42.
A refactoring suggestion in SonarQube. Source: Oswal 2019, fig. 42.

Oswal studies the support for technical debt in three tools: SonarQube, PMD and Code Analytix. He notes that no single tool gives a holistic view and therefore he uses multiple tools for this analysis. The study looks at the Core Java 8 project plus a web application (Java/JavaScript/HTML/XML). The study addresses software reliability, maintainability and security.

References

  1. Codabux, Zadia, and Byron Williams. 2013. "Managing technical debt: An industrial case study." Proceedings of 4th International Workshop on Managing Technical Debt, pp. 8-15. doi: 10.1109/MTD.2013.6608672. Accessed 2020-07-15.
  2. Cunningham, Ward. 1992. "The WyCash Portfolio Management System." Experience Report, OOPSLA'92, March 26. Accessed 2020-07-15.
  3. Fowler, Martin. 2019. "Technical Debt." ThoughtWorks, May 21. Accessed 2020-07-05.
  4. Letouzey, Jean-Louis. 2016. "Managing Technical Debt with the SQALE Method." Cutter IT Journal, pp. 16-20, March. Accessed 2020-07-15.
  5. Letouzey, Jean-Louis, and Thierry Coq. 2010. "The SQALE Analysis Model: An Analysis Model Compliant with the Representation Condition for Assessing the Quality of Software Source Code." Second International Conference on Advances in System Testing and Validation Lifecycle, IEEE, pp. 43-38, August 22-27. doi: 10.1109/VALID.2010.31. Accessed 2020-07-15.
  6. Li, Zengyang, Paris Avgeriou, and Peng Liang. 2015. "A systematic mapping study on technical debt and its management." Journal of Systems and Software, vol. 101, issue C, March. doi: 10.1016/j.jss.2014.12.027. Accessed 2020-07-15.
  7. Martini, Antonio, and Jan Bosch. 2015. "The Danger of Architectural Technical Debt: Contagious Debt and Vicious Circles." Proceedings of 12th Working IEEE/IFIP Conference on Software Architecture, May 5. Accessed 2020-07-15.
  8. Nord, Robert. 2016. "The Future of Managing Technical Debt." Blog, Software Engineering Institute, August 29. Accessed 2020-07-15.
  9. Osetskyi, Victor. 2018. "What Technical Debt Is and How to Calculate It." DZone, July 13. Accessed 2020-07-15.
  10. Oswal, Nikhil. 2019. "Technical Debt: Identify, Measure and Monitor." arXiv, v1, October 28. Accessed 2020-07-15.
  11. Papapetrou, Patroklos. 2015. "How to Calculate Technical Debt and Express It Clearly." Blog, ThinkApps, November 12. Accessed 2020-07-15.
  12. Papapetrou, Patroklos. 2016. "Technical Debt Computation: Comparison of Top Tools." Blog, ThinkApps, February 16. Accessed 2020-07-15.
  13. Parthiban, Dwarak Govind. 2019. "Examination of tools for managing different dimensions of Technical Debt." arXiv, v1, April 24. Accessed 2020-07-15.
  14. Pavlič, Luka and Tilen Hliš. 2019. "The Technical Debt Management Tools Comparison." In: Z.Budimac and B. Koteska (eds.), Proceedings of the SQAMIA 2019: 8th Workshop on Software Quality, Analysis, Monitoring, Improvement, and Applications, September 22–25. Accessed 2020-07-15.
  15. Radigan, Dan. 2015. "3 steps to taming technical debt with Jira." Blog, Atlassian, April 1. Accessed 2020-07-15.
  16. Scrum Expert. 2016. "Tools to Assess and Manage Technical Debt." Scrum Expert, February 9. Accessed 2020-07-15.
  17. Sharma, Tushar and Ganesh Samarthyam. 2015. "Limitations of Technical Debt Quantification: Do you Rely on these Numbers?" InfoQ, August 12. Accessed 2020-07-15.
  18. SonarQube Docs. 2020a. "Analyzing Source Code: Overview." SonarQube Docs, v8.4, SonarSource. Accessed 2020-07-15.
  19. SonarQube Docs. 2020b. "Analyzing Source Code: Analysis Parameters." SonarQube Docs, v8.4, SonarSource. Accessed 2020-07-15.
  20. SonarSource. 2020. "History." SonarSource. Accessed 2020-07-15.
  21. Vector Informatik. 2020. "Squore/Software Analytics for Software Project Quality and Performance." Squore, Vector Informatik GmbH. Accessed 2020-07-15.
  22. Wolff, Eberhard, and Sven Johann. 2013. "Managing Technical Debt." InfoQ, May 6. Accessed 2020-07-15.
  23. Yli-Huumo, Jesse, Andrey Maglyas, and Kari Smolander. 2016. "How do software development teams manage technical debt? – An empirical study." Journal of Systems and Software, vol. 120, pp. 195-218, October. Accessed 2020-07-15.

Further Reading

  1. Li, Zengyang, Paris Avgeriou, and Peng Liang. 2015. "A systematic mapping study on technical debt and its management." Journal of Systems and Software, vol. 101, issue C, March. doi: 10.1016/j.jss.2014.12.027. Accessed 2020-07-15.
  2. Letouzey, Jean-Louis. 2016. "Managing Technical Debt with the SQALE Method." Cutter IT Journal, pp. 16-20, March. Accessed 2020-07-15.
  3. Oswal, Nikhil. 2019. "Technical Debt: Identify, Measure and Monitor." arXiv, v1, October 28. Accessed 2020-07-15.
  4. Parthiban, Dwarak Govind. 2019. "Examination of tools for managing different dimensions of Technical Debt." arXiv, v1, April 24. Accessed 2020-07-15.
  5. Pavlič, Luka and Tilen Hliš. 2019. "The Technical Debt Management Tools Comparison." In: Z.Budimac and B. Koteska (eds.), Proceedings of the SQAMIA 2019: 8th Workshop on Software Quality, Analysis, Monitoring, Improvement, and Applications, September 22–25. Accessed 2020-07-15.
  6. Nord, Robert. 2016. "The Future of Managing Technical Debt." Blog, Software Engineering Institute, August 29. Accessed 2020-07-15.

Article Stats

Author-wise Stats for Article Edits

Author
No. of Edits
No. of Chats
DevCoins
Avatar of user arvindpdmn arvindpdmn
2
0
1173
DevCoins due to articles, chats, their likes and article hits are included.
1457
Words
1
Authors
2
Edits
0
Chats
0
Likes
7276
Hits

Cite As

Devopedia. 2020. "Tools to Manage Technical Debt." Version 2, July 15. Accessed 2023-11-12. https://devopedia.org/tools-to-manage-technical-debt
Contributed by
1 author

Last updated on
2020-07-15 13:46:51

Improve this article

Article Warnings

  • Readability score of this article is below 50 (49.4). Use shorter sentences. Use simpler words.