Every company should have a little technical debt, but keeping it below the recommended 5% can be challenging. If companies aren’t careful, the debt can grow to 10%, 50%, or even 80-90% in extreme cases. According to McKinsey, the average technical debt is between 20% and 40%. Repaying that quantity of debt takes planning, vigilance, and continuous attention. It takes building and executing on a technical debt roadmap to balance the needs of the present while paying down the technical debt from the past.
Organizations with financial debt understand debt and its effects. They evaluate different repayment options. They crunch numbers and perform analyses until they’ve created a repayment plan that doesn’t constrict growth but does lower the debt. Executives understand that debt can hamper innovation and growth. With less money to invest in new product development, businesses lose their edge over competitors with less debt.
Despite their understanding of financial debt, most companies fail to apply the same principles to technical debt. There’s little planning, and decisions are rarely based on data. As a result, enterprises invest in applications that don’t lower technical debt. They devote resources to solutions that are reaching their end of life. Executives struggle to find a place to start.
Without a Technical Debt Roadmap
The 2022 McKinsey study mentioned above included 220 organizations across different business sectors, and it found that the percentage of technical debt a company has correlates with business performance. Of the participating companies, those with the lowest technical debt ratio experienced 20% higher revenue growth than those with the highest debt ratio.
The study calculated technical debt via a “Technical Debt Score” (TDS) value, and the research found that businesses in the bottom 20% of technical debt, with the poorest TDS, were 40% more likely to cancel or fail to complete modernization efforts.
The top performers spent, on average, 50% more on modernization than those in the lowest percentiles. As they paid down their debt, they remained disciplined in how and where they spent their technology dollars. These companies learned through the process how to use technology to drive innovation and increase revenue.
Related: Eliminating Technical Debt: Where to Start?
Originally, technical debt referred to the consequences of software developers placing delivery deadlines over technical, architectural, or design considerations. It’s what happens when shortcuts in code quality are taken to meet customer requirements. Today’s technical debt has expanded to include any decision that impacts a company’s technology stack.
Determining the size of technical debt is the first step in creating a roadmap. The process should encompass such factors as:
- Defect Ratios
- Completion Time
- Rework
- Code Quality
- Architectural Debt
Some of these factors are easier to assess, while others require more intensive analysis, such as code quality. However, all factors should be evaluated to ensure a solid technical debt roadmap.
Defect Ratios
No application is perfect; however, the older the software, the fewer the defects. When the reverse happens, the defect ratio increases. The result is a growing technical debt. If left unchecked, the software may reach a point where it is irreparable. The legacy solution can no longer operate in a modernized construct.
Completion Time
When an engineer or developer is assigned trouble or support tickets, how long does it take to complete them? Focusing on low-priority tickets can identify a growing technical debt. For example, an incorrect value appears in a report. Because the legacy code uses tables instead of databases, the developer has to determine how the software produces the value used in the report. In a monolithic architecture, tracing the value could require combing through hundreds of lines of code. If the value is calculated, the time to resolve increases.
Rework
Reworking the same code segment indicates a technical debt. An employee opens a support ticket for a legacy utility. The assigned developer sees it’s an easy fix and completes it in less than an hour. A week later, another developer accesses the same module to fix a different support ticket. This correction takes a little longer and requires reworking the first fix. When programmers are making fixes to fixes, it’s an indication that technical debt is accruing.
Code Quality
Code quality requires more in-depth analysis than higher-level assessments, such as total defects or rework statistics. Quality code in relation to technical debt encompasses lines of code, code complexity, inheritance, maintainability, nesting, and couplings. Assessing quality may require tools to look at specific parameters to identify coding flaws.
Architectural Debt
Academic research that started in 2012 with “In Search of a Metric for Managing Architectural Technical Debt”, authors Robert L. Nord, Ipek Ozkaya, Philippe Kruchten and Marco Gonzalez-Rojas created a metric to measure architectural technical debt based on dependencies between architectural elements. They use this method to show how an organization should plan development cycles and roadmap investments that take into account the effect that accumulating technical debt will have on the overall resources required for each subsequent version released. This breakthrough study recently received the “Most Influential Paper” award at the 19th IEEE International Conference on Software Architecture.
Assessing Code Quality
When evaluating legacy code, poor quality doesn’t mean poor programming. It means evaluating legacy systems in terms of today’s coding standards. For example, older architectures created one large monolithic application consisting of thousands of lines of code. The software was designed to run on a single on-premise server. Today’s architecture breaks that large application into smaller microservices better suited to a cloud environment.
Assessing code quality provides data for resolving technical debt. It uses the following metrics to determine the status of individual applications that can be used to create a technical debt roadmap.
Risk Index
Code dependencies are the bane of modernization efforts. Depending on how long the legacy system has existed, and the number of programmers who worked on it, finding dependencies is like looking for Waldo. They are difficult to find. They may be buried among lines of code, but failing to address them beforehand can become a career-changing move.
Paying back a technical debt should not result in an unexpected application shutdown. With the right tools, organizations can identify dependencies to be evaluated before changes are made, reducing the risk of an epic fail.
Complexity Index
Think of the complexity index as strings of lights. Is there anything more frustrating than trying to untangle holiday lights? A complexity index identifies how entangled class dependencies are. Like light strings, a few dependencies can be untangled and put to use. Too many dependencies may make it too costly to isolate into microservices. Knowing that upfront makes it easier to assess whether to retain or replace a legacy solution.
Debt Index
A debt index provides an overall assessment of an application’s technical debt. It combines the risk and complexity indices and compares the results with other applications. Sorting the debt index from high to low can be the start of a technical debt roadmap.
Accepting the debt index without evaluating the complexity and risk values can skew the roadmap. Although complex entanglements often correlate with high risk, organizations must look at the details. After all, quality code is always about the details.
Frameworks
As technologies advance, so do the frameworks. What was considered the leading edge two years ago has become a standard that everyone uses. Frameworks that existed for decades may no longer run on supported operating systems. Dependencies may tie to third-party solutions that do not exist. These aging frameworks pose security risks.
A recent example of security risks in existing frameworks is the Log4j vulnerability discovered in December 2021. This flaw was a zero-day vulnerability to Apache’s logging software. Although Apache had released later versions, many organizations retained the older version for compatibility with existing architectures.
Understanding the weaknesses in older frameworks should be part of every technical debt roadmap. If vulnerabilities can be patched, an older framework may place lower on the modernization list than a newer framework with no available security patches.
Future Proof
Technical debt happens every day. Companies make decisions to make a quick fix to get a business-critical solution back in operation as quickly as possible. Maybe the delivery date for fixing the code doesn’t allow for the necessary rework. A patch is delivered instead, and technical debt increases.
Modernizing existing architecture also requires that solutions are compatible with the latest compilers, libraries, and frameworks. Staying as current as possible reduces ongoing technical debt. With less time spent on lowering debt, businesses can devote more resources to innovation and growth.
Related: Go-to Guide to Refactoring a Monolith to Microservices
Creating a Modernization Roadmap
Part of creating a technical debt roadmap is deciding how best to address the modernization. Options may include refactoring, re-platforming, and rearchitecting. Each approach may be part of an organization’s plan to lower technical debt.
Refactoring turns messy code into clean code. Clean code has fewer complexities, eliminates duplication, and makes for easier maintenance. Messy code can take longer to compile or throw errors that are corrected multiple times by different programmers. With large projects and multiple programmers, it’s easy to lose control over the code. Refactoring cleans code so it can run faster and improve performance.
Replatforming
Replatforming adds functionality to take advantage of cloud infrastructures. It doesn’t modify the application. It can improve an application’s ability to scale and expedite interactions with cloud-based data stores. It can be a cost-effective way to leverage cloud functionality without the cost of replacing or rearchitecting code.
Rearchitecting
Designing an application to operate in the cloud means rearchitecting the application. Developers and engineers are starting from the ground up when it comes to redesigning an existing solution to operate as a cloud-native application. While building an application may be labor-intensive, it may be the only solution to modernizing an existing solution.
Managing Technical Debt
The McKinsey article referred to technical debt as dark matter. It exists. Its impact is measurable, but it can’t be seen or measured. At vFunction, we politely disagree. Technical debt is quantifiable through automated tools that leverage advanced technologies, such as artificial intelligence, to move monolithic structures to microservices for cloud-native deployment.
If you’re interested in creating a technical debt roadmap based on data, request a demo of our platform. Our team is excited to show you how to quantify and lower your technical debt.
