How to estimate the tremendous value of technical debt work

When teams face the challenge of prioritizing technical debt, most of them (or at least the ones I have worked with) end up arguing “intangible” value or some variation of “this will benefit us in the future so we can’t really measure it today”. Invariably this makes stakeholders want to avoid this “not-so-visible value” type of work. And it also gives Product Managers hard work when trying to prioritize technical debt-related activities. The good news is that the “intangible” argument doesn’t make any sense. There are real, very concrete benefits of having great quality software and you should strive to make those values visible to everyone from the team working on that technical debt (focus them on the outcome, not the output), to the highest level stakeholders (who are being asked to “delay” other business valued work). How do we measure the value At this point, I do have to agree that in some cases this benefit is indeed hard to quantify. But in my experience, this difficulty arises from the type of work and outcome expected. So instead of saying “all technical debt is hard to value”, let’s break it down into types. Performance Source: pixabay.com One of the most frequent impacts of technical debt reduction is system performance. It can be decreasing response time, but it may also mean being able to serve more or larger requests with the same infrastructure or even reducing infrastructure cost. This is pretty easy to measure: For response time either you have a performance KPI, or you can correlate something like the increase in conversion, usage or user satisfaction with your better performance. For the number of requests and costs, you should also have KPIs that can show the impact of newer versions technically improved Maintainability One of the biggest impacts of technical debt reduction is system maintainability You will be able to deliver business value faster. You will have more successful deploys because when you change a piece of your software it is less likely you will break some other piece. You will be able to faster adopt newer technologies Again, there are several ways to measure it. One of the easiest ways is static code analysis. Metrics like cyclomatic complexity, depth of inheritance, class coupling, and many more can be analyzed with easy to implement tools like SonarQube. The ones more useful for the business will need some more longitudinal tracking: reduction in lead time over time, deploy success over time, time to change libraries versions, etc etc. Reusable Architecture Photo by on Johny vino Unsplash Related to deliver business value faster, if you can create pieces of your systems that can be reused in other use cases, you will implement those new functionalities faster. Once more, this is easy to measure: subtract the cost of implementing the feature reusing the module to the cost without reducing it. And as a side benefit, the system will be easier to maintain. If you have to change something in the reused module, it will have an impact on all the functionalities that use that module without having to work on two separate items. Reliability Many times when technical debt is removed you either reduce errors or you increase your capabilities to recover from them. A good example of this type of technical debt is not having a good logging system. When you work to create better logging, the business would not perceive any increased value. However, the next time something goes wrong you will be able to fix it faster, and the business will reap the benefits. How can you measure it? A reduction in Mean Time To Detection (MTTD) and Mean Time To Resolution (MTTR) over time. Team autonomy Another symptom of high rates of technical debt is having a monolithic architecture that not only causes many of the above-mentioned problems but also reduces your ability to work in a product organization with highly independent teams. Talking about team autonomy would make me drift away from the topic of this article. But to say it in a few words, we want teams with clear vision and goals, with the autonomy and accountability to accomplish them. When your monolithic app makes every new implementation a multi-team effort where everyone needs help from others to accomplish their goals, or the implementations of any team keeps “disturbing” the initiative of others, then accountability goes down and the team does not have the ability to go fast and accomplish their vision. Autonomy may be the hardest of this attributes to measure. A high-level proxy may be the team’s self-reported autonomy in surveys like “Team Healthcheck” or other agile related team’s self-assessment. A more precise count can be the number of releases that require multiteam efforts (or count of push requests from one team to another), but this metric may vary according to work type and not necessarily due to architecture improvements. Conclusion Fixing technical debt drives a lot of value. Yes, that value is sometimes hard to measure. This is a call to all technical fellows to make that value estimation effort. Companies (and users!) are losing all that value because we are doing a poor job of justifying these investments, so stakeholders are pushing to prioritize other work. I hope this article helps to give some starting points for that estimation. Thanks for reading! I would love to hear feedback (or claps!) and your stories about technical debt value estimation. If you enjoyed it and want to receive more tools & tips to improve your product, you can subscribe here and join hundreds of readers!