So one of the biggest challenges I’ve repeatedly heard about technical debt is that although the delivery team knows it exists, there is no easy way to measure the actual cost of technical debt. However, there are ways to help bridge the unspecific to the specific.
With technical debt, using a financial analysis of comparing addressing the technical debt now versus addressing the technical debt later (at a pre-determined point) will bring useful data to make informed decisions.
So how accurate is that data? What level of confidence will leaders place on it? One method to help bridge that trust gap would be to use technical debt evaluation tool like SonarQube that can give detailed counts of technical debt risks. This can then be used as a “ground level up” method of determining the full cost of fixing technical debt now and given as detailed evidence that this isn’t simply “developer guesswork”. From organizing the reported debt, the seven axes of Quality reported by SonarQube can then be mathematically estimated and used as supporting evidence.
The example chart gives a comparison that non-technical employees can understand. This speaks in clear financial figures and can be measured to determine progress and where key decisions can be made.
No longer does technical debt have to be the software delivery department wrestling with business. There can be a common ground for discussion, collaboration and agreement on how much effort should be made to resolve any accrued technical debt.