Tools to Manage Technical Debt

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? 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? 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? 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
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.
2009

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.
2015

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.
2015
2018
2019

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
- 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.
- Cunningham, Ward. 1992. "The WyCash Portfolio Management System." Experience Report, OOPSLA'92, March 26. Accessed 2020-07-15.
- Fowler, Martin. 2019. "Technical Debt." ThoughtWorks, May 21. Accessed 2020-07-05.
- Letouzey, Jean-Louis. 2016. "Managing Technical Debt with the SQALE Method." Cutter IT Journal, pp. 16-20, March. Accessed 2020-07-15.
- 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.
- 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.
- 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.
- Nord, Robert. 2016. "The Future of Managing Technical Debt." Blog, Software Engineering Institute, August 29. Accessed 2020-07-15.
- Osetskyi, Victor. 2018. "What Technical Debt Is and How to Calculate It." DZone, July 13. Accessed 2020-07-15.
- Oswal, Nikhil. 2019. "Technical Debt: Identify, Measure and Monitor." arXiv, v1, October 28. Accessed 2020-07-15.
- Papapetrou, Patroklos. 2015. "How to Calculate Technical Debt and Express It Clearly." Blog, ThinkApps, November 12. Accessed 2020-07-15.
- Papapetrou, Patroklos. 2016. "Technical Debt Computation: Comparison of Top Tools." Blog, ThinkApps, February 16. Accessed 2020-07-15.
- Parthiban, Dwarak Govind. 2019. "Examination of tools for managing different dimensions of Technical Debt." arXiv, v1, April 24. Accessed 2020-07-15.
- 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.
- Radigan, Dan. 2015. "3 steps to taming technical debt with Jira." Blog, Atlassian, April 1. Accessed 2020-07-15.
- Scrum Expert. 2016. "Tools to Assess and Manage Technical Debt." Scrum Expert, February 9. Accessed 2020-07-15.
- Sharma, Tushar and Ganesh Samarthyam. 2015. "Limitations of Technical Debt Quantification: Do you Rely on these Numbers?" InfoQ, August 12. Accessed 2020-07-15.
- SonarQube Docs. 2020a. "Analyzing Source Code: Overview." SonarQube Docs, v8.4, SonarSource. Accessed 2020-07-15.
- SonarQube Docs. 2020b. "Analyzing Source Code: Analysis Parameters." SonarQube Docs, v8.4, SonarSource. Accessed 2020-07-15.
- SonarSource. 2020. "History." SonarSource. Accessed 2020-07-15.
- Vector Informatik. 2020. "Squore/Software Analytics for Software Project Quality and Performance." Squore, Vector Informatik GmbH. Accessed 2020-07-15.
- Wolff, Eberhard, and Sven Johann. 2013. "Managing Technical Debt." InfoQ, May 6. Accessed 2020-07-15.
- 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
- 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.
- Letouzey, Jean-Louis. 2016. "Managing Technical Debt with the SQALE Method." Cutter IT Journal, pp. 16-20, March. Accessed 2020-07-15.
- Oswal, Nikhil. 2019. "Technical Debt: Identify, Measure and Monitor." arXiv, v1, October 28. Accessed 2020-07-15.
- Parthiban, Dwarak Govind. 2019. "Examination of tools for managing different dimensions of Technical Debt." arXiv, v1, April 24. Accessed 2020-07-15.
- 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.
- Nord, Robert. 2016. "The Future of Managing Technical Debt." Blog, Software Engineering Institute, August 29. Accessed 2020-07-15.
Article Stats
Cite As
See Also
- Technical Debt
- Clean Code
- Code Smell
- Static Code Analysis
- Code Refactoring
- Code Reuse
Article Warnings
- Readability score of this article is below 50 (49.4). Use shorter sentences. Use simpler words.