To meet the challenges posed by both customers and competitors in today’s rapidly-changing marketplace, companies must regularly update and modernize the software applications upon which their business operations depend. In such an environment, technical debt is both inevitable and highly detrimental to these goals. That’s why it’s vitally important for IT leaders to know how to measure technical debt and manage it effectively.
According to Gartner, companies that do a good job of managing technical debt “will achieve at least 50% faster service delivery times to the business.” On the other hand, organizations that fail to properly manage their technical debt can expect higher operating expenses, reduced performance, and a longer time to market. As a report from McKinsey makes clear,
“Poor management of tech debt hamstrings companies’ ability to compete.”
Why Knowing How to Measure Technical Debt is Crucial
Many companies today depend on traditional monolithic applications for business-critical processing. Due to their age and development over time, such apps typically have a substantial degree of technical debt that limits their ability to integrate and take advantage of today’s cloud-based technological ecosystem.
The solution is to modernize those legacy apps to give them essentially cloud-native capabilities. And that means dealing with the technical debt that’s holding them back. But, as management guru Peter Drucker famously said,
“You can’t improve what you don’t measure.”
Being able to measure the technical debt of legacy apps is key to bringing them into the modern technological age. One recent application modernization white paper explains it this way:
“For any application modernization strategy to be successful, organizations need to first understand the complexity, risk, and technical debt of their current application estate. From there they can prioritize and make the appropriate substantial investments into technology, resources, and the time it takes to implement the strategy.”
But technical debt is notoriously difficult to identify and measure. To understand why, let’s take a deeper dive into exactly what technical debt is and how it manifests itself.
Related: Why Modernize Legacy Applications?
What is Technical Debt?
The term was coined in 1992 by computer scientist Ward Cunningham to describe the impact of the short-term compromises and workarounds developers often incorporate into their code. As TechTarget explains,
“Software development and IT infrastructure projects sometimes require leaders to cut corners, delay features or functionality, or live with suboptimal performance to move a project forward. It’s the notion of ‘build now and fix later.’ Technical debt describes the financial and material costs that come with fixing it later.”
In effect, technical debt is the result of developers prioritizing speed over quality.
Disadvantages of Technical Debt
Since no software development project is ever blessed with all the time or resources required to produce a perfect codebase, some degree of technical debt is unavoidable. That’s not necessarily bad if an application’s technical debt is promptly “paid off.” Otherwise, just as with financial debt, the costs of repaying the “principal” plus the “interest” on the debt can eventually reach crippling proportions.
The principal on technical debt is the cost of fixing the original code, dependencies, and frameworks to enable it to function in today’s technology environment. The interest is the added cost of maintaining such applications, which continues to compound over time. Keeping an aging and inflexible legacy application running as it becomes more and more incompatible with the rapidly changing modern infrastructure in which it must operate is the challenge.
Technical debt can be a huge drag on a company’s ability to innovate. According to Gartner, by 2025 companies will be spending 40% of their IT budgets on simply maintaining technical debt.
And there are other costs of technical debt that are, perhaps, even worse than the financial ones:
- Less innovation: The time developers devote to dealing with technical debt is time taken away from developing the innovations that can propel the business forward in its marketplace.
- Slow test and release cycles: Technical debt makes legacy apps brittle (easy to break), opaque (hard to understand), and difficult to upgrade safely. That means more time must be devoted to understanding the potential impact of changes and testing them to ensure they don’t cause unexpected disruptions in the app’s operation.
- Inability to meet business goals: This is the inevitable result of the previous two issues. In today’s environment of rapid evolution in both technology and market requirements, the inability to quickly release and deploy innovative new applications can cripple a company’s ability to meet its goals.
- Security exposures: Because modern security concerns were typically unknown or disregarded when older apps were designed or patched, security-related technical debt often constitutes a major vulnerability for legacy code.
- Poor developer morale: For many developers, dealing with technical debt can be mind-numbing and frustrating. In one survey, 78% of respondents affirmed that “paying down technical debt” negatively impacted their personal morale.
Ward Cunningham explains the destructive potential of technical debt this way:
“The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation.”
Related: 3 Reasons Your Digital Transformation Stalled
How to Measure Technical Debt
As we’ve seen, companies need to understand how to manage technical debt. Yet, according to an article in Forbes, technical debt is difficult to measure. The article quotes Sven Blumberg and Björn Münstermann of McKinsey as saying,
“Technical debt is like dark matter: you know it exists, you can infer its impact, but you can’t see or measure it.”
Blumberg and Münstermann list some informal indicators of technical debt, such as product delays, out-of-control costs, and low developer morale. But, are there any formal methods available to quantify the amount of technical debt that characterizes a particular application or an entire application portfolio?
Some have proposed using metrics such as cyclomatic complexity (the number of possible execution paths in the code) and cognitive complexity (a measure of the difficulty a human would have in understanding the code and all its possible execution paths). The problem with such indicators is the difficulty of measuring them in a large monolithic codebase with perhaps millions of lines of code.
Using Machine Learning to Measure Technical Debt
Much of the technical debt in legacy apps arises from their monolithic architecture and reliance on aging technologies. In such apps, the codebase is organized as a single entity that has hidden dependencies embedded throughout. Unraveling such dependencies is indispensable for measuring technical debt.
In 2012, a team of researchers published an article entitled, “In Search of a Metric for Managing Architectural Technical Debt“. In this article, which was awarded the “Most Influential Paper” Award at the 19th IEEE International Conference on Software Architecture (ICSA 2022), they describe a means of measuring technical debt based on dependencies between architectural elements in the code. Their methodology has now been adopted as the basis for a practical approach to using machine learning to measure technical debt.
This new approach quantifies an application’s level of technical debt based on the dependency graph between its classes. According to one definition,
A dependency graph is a data structure formed by a directed graph that describes the dependency of an entity in the system on the other entities of the same system. The underlying structure of a dependency graph is a directed graph where each node points to the node on which it depends.
In this case, the vertices on the graph represent the set of all classes in the application, while the edges in the graph identify dependencies between classes. By using machine learning (ML) to identify, analyze, and quantify factors such as these, it’s possible to develop a three-pronged score that represents the level of technical debt in the application. The three elements of the technical debt score are:
- Complexity — represents how much effort is required to add new features to the app.
- Risk — relates to the potential that adding new features to the app may disrupt the operation of existing ones.
- Overall Debt — quantifies the amount of additional work that’s required when adding new features.
After being trained based on manual analyses that incorporated the expert knowledge of experienced architects and developers, the ML model was able to provide accurate debt-level scores for applications it had not seen before. By applying this method across its entire legacy software portfolio, a company can develop a global view of technical debt in its applications, both individually and as a whole. This, in turn, provides the information IT leaders need to determine which apps should be modernized to pay down technical debt and in what order.
Using Intelligent Tools to Effectively Modernize Legacy Apps
For machine learning to be a practical solution to the problem of how to measure technical debt, that solution must be embodied in an intelligent, AI-driven, automated analysis tool. Such a tool must be able to deliver comprehensive technical debt metrics that allow users to build a data-driven business case for modernizing a company’s suite of legacy apps. These metrics should identify the level of technical debt, complexity, and risk for each app and for the legacy app portfolio as a whole.
vFunction Assessment Hub is a purpose-built platform that embodies those principles and more. Not only does it use machine learning to provide accurate measures of technical debt, but it can also automatically refactor legacy apps to eliminate technical debt.To see vFunction’s answer to the question of how to measure technical debt in action, schedule a demo today.