Technical Debt
Concept
Technical Debt is used to address the non-quality of a software project. It is evaluated in time unit (man day), or actual cost (monetary value), based on the remediation cost of all default which have been found in the project.
Technical Debt represents the effort to fix all quality issues in the project.
Utility
Using Technical Debt helps anticipate future issues the development team will face. The more debt a project has, the more difficult the development will be. High debt often reveals a low ratio of "new features", as team spends its time in understanding and fixing current issues.
Technical Debt = Maintainability?
No, Technical Debt concept is not limited to Maintainability, and can be extended to other ISO quality characteristics: maintainability, portability, reliability, security, efficiency.
However, quality issues other than Maintainability are most of the time addressed during development because they are part of the delivery requirements (ie: no reliability issue shall be detected in the delivered product…).
Maintainability is often considered as rather "Nice to Have" than "Mandatory". As a consequence, technical debt is (wrongly) associated to Maintainability.
Computation
Technical Debt computation is based on quality issues provided by Static Code Analysis. Each issue is associated to a remediation cost, mapped to a time effort.
Formula: sum(#violations * remediation cost)
Remediation Cost:
Remediation Cost |
Minutes |
|---|---|
Low |
10 |
Medium |
30 |
High |
60 |
Huge |
480 |
|
Squore uses the ISO mapping to provide Technical Debt trend according quality breakdown. |
|
Technical Debt is based on the findings provided by the static analyzers. Its value may vary depending on the analyzer which is used (in case they do not generate the same amount of issues). Activating a maximum number of programming rules during static code analysis increases the confidence level in the technical debt results. |
How to Address Technical Debt with Squore
Finding the Right Project
At project portfolio level, Squore provides a Technical Debt chart highlighting the distribution of all projects according their technical debt density (=average of technical debt per 1000 lines of code). Interpretation:
-
Projects in the top area have a higher Technical Debt Density meaning they are more difficult to maintain,
-
Projects in the right area are bigger (wrt. Line counting),
-
The bubble size is proportional to the "number of programing rules which have been activated during static analysis". A larger bubble means a higher confidence in technical debt value.
Finding the Right Function
Inside a project, Squore provides a Technical Debt chart highlighting the distribution of all modules (i.e. functions) according to their technical debt and their violations density (density of issues weighted by severity). Interpretation:
-
Modules in the top area have a higher Technical Debt meaning they are more difficult to maintain,
-
Modules in the right area are bigger (wrt. Line counting),
-
The bubble color shows the severity of issues inside the components.
