Stop Measuring Technical Debt, Start Measuring Risk & Value
A common problem facing any applications practice is dealing with technical debt. Technical debt, or tech debt for short, is the resulting back-end inadequacies of an application from either inadvertent error or prioritizing speed of delivery over quality. The former cause is somewhat inevitable and generally results from not having the proper checks and balances in place. The latter cause is the more frustrating scenario. Delivery teams, often outside of their control, opt for quick or cheap solutions and put off the more comprehensive or quality-assured option for a time when capacity allows, which often never comes. That gap represents deliberate technical debt. The reality is virtually all organizations are required to accept this deliberate tech debt to some degree, but it will eventually catch up with you and cause problems for both IT and the business.
Getting out of this problem is difficult. The natural instinct of many is to start with asking: How can I measure technical debt? What types of code analytics should I perform? What kind of metrics should I be after; lines of sub-optimal code, code duplication, rule violations, deferred features, or technical debt ratio?
I wouldn’t suggest that this approach is incorrect or that this information is irrelevant. Quite the opposite. Many development shops are in dire need of more of this type of analysis. However, it’s only painting half the picture when the real goal is to draw attention to the extent of the problem.
As mentioned, this scenario is caused by a balance of priorities that skew delivery efforts to speed over quality. That same sense of priority is likely to impact any efforts or buy-in for resolving tech debt as well. You need to change how you present the issue to the decision makers (DMs) of your application portfolio or ultimately who signs off on any refactoring or modernization efforts.
If there’s one point to get across, when that DM isn’t technically oriented, the measure of tech debt means very little if it isn’t both clearly linked to a business capability and articulated as risk to that capability. The case that needs to be made here is tech debt is technical risk, it’s business risk. Therefore, you shouldn’t express tech debt using solely technical or code-based metrics. It needs to be measured in terms of things like business continuity, production efficiency, or barriers to growth, for example. When selecting an APM tool, which is one of your best weapons in the fight against tech debt, you need to make sure you have a solution that paints the full picture.
Cast Highlight does this well. It collects business value information integral to any application rationalization effort, but specifically presents it in a comparison between application value and software complexity, production risk, and adaptability risk.
Figure 1: Risk map; courtesy of Cast Highlight
So, the argument to your DMs isn’t this high value application has poor technical health. The argument is this high value application won’t:
- Meet your production targets
- Meet your availability requirements
- Guarantee data privacy and security
- Allow for you to accomplish the goals you’ve set to grow the business
Think of application rationalization as a risk management function. A simple rationalization model compares technical health to business value. A simple risk management model compares the likelihood of a threat with the impact of that threat. With respect to technical debt, they are essentially the same variables in these analyses, and both are designed to prompt a call to action to when risk is present in a high-value area.
Green = DO SOMETHING
In both of these scenarios the business will understand the value and impact, where IT is more knowledgeable in suggesting the technical health of likelihood of the application or risk. It’s up to the role risk manager or application portfolio manager to compile this information and to push the DM in the right direction to act on that call to action.
Our Take
Yes, measure technical debt. But, translate it into something that will resonate with the business.
Find out what will “resonate with the business!” So many application teams attempt rationalization or undergo some effort to address technical debt and don’t have an answer to that question. Technical debt is risk. Determine what risks will get your DMs moving.
Transfer risk, or at least create a sense of shared risk. This means blurring the line between the technology and the business capability. Don’t view tech debt as unhealthy applications – it’s unhealthy capabilities.
Be proactive as well. When determining the quick vs. comprehensive option, ensure you have an accurate sense of the business and technical priorities behind that decision; and that the eventual comprehensive option is properly injected into your backlog and not thrown to the curb.