If, as McKinsey declares, every company is a software company, then it’s equally true that at some level, every company has a technical debt problem. As McKinsey also says, “Almost every business has some degree of tech debt” and “Poor management of tech debt hamstrings companies’ ability to compete.” With 86% of IT executives reporting that their companies were impacted by technical debt over the last year, it’s an issue that can significantly affect any business that depends on software for its internal operations or customer interactions.
And yet, although 94% of companies recognize the importance of managing their technical debt, 58% have no formal strategy for doing so. Why such neglect? With many areas of the business competing for support, the ROI of modernizing legacy apps to eliminate technical debt simply hasn’t been clear enough to make it a priority.
But that reality represents an opportunity for software architects and development teams, which have traditionally assumed a somewhat hands-off and reactive stance toward business matters, to take on a bigger role in their organization. They can do so by making a compelling business case for why managing technical debt is critical for helping the company meet its strategic objectives. In this article, we want to help make that case. Let’s start by looking at why technical debt is such an important issue.
What Is Technical Debt?
The Journal of Systems and Software defines technical debt as “sub-optimal design or implementation solutions that yield a benefit in the short term but make changes more costly or even impossible in the medium to long term.” Ward Cunningham, who coined the term in 1993 to highlight the long-term costs of taking design or implementation shortcuts to release software more quickly, describes those costs this way:
“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.”
The impact of Cunningham’s insight can be seen in the fact that engineers now spend about a third of their time fixing technical debt issues, siphoning off 10%-20% of their company’s new product technology budget in the process.
Who’s Responsible for Technical Debt?
In general, there’s no single source of technical debt. It often results from the need to release software as quickly as possible. Sometimes it reflects a misalignment between business requirements and development specifications or practices. Or it may be caused by the fact that once launched into the real world, apps frequently require quick, ad hoc changes that may not align with the original architectural design.
Related: Eliminating Technical Debt: Where to Start?
But the fact that technical debt usually cannot be traced to any definite source can be a distinct advantage. It allows software architects and developers to advocate for prioritizing application modernization to minimize technical debt without provoking resistance from other stakeholders who might feel that such an emphasis points a finger of blame in their direction.
Types of Technical Debt
From an app design standpoint, there are three major types of technical debt:
- Code-level technical debt: This type of debt arises from shortcuts or errors inserted into the code as it is being developed or updated. It can severely limit the readability and maintainability of the codebase.
- Component-level technical debt: Components are logically modular units of code that should ideally be self-contained. But legacy app components are frequently tightly coupled and interdependent. That, along with any design, performance, or scalability issues, can create a significant amount of technical debt.
- Architectural-level technical debt: This refers to technical debt that is built into an app before coding even starts due to shortcomings in its architectural design. A good example is the monolithic architecture that typically characterizes legacy Java apps. A monolithic codebase is organized as a single unit that has functional implementations and dependencies interwoven throughout. Because any change might ripple through the codebase in unexpected ways, potentially causing the app to fail, monolithic apps can be extremely difficult to maintain and update.
Gartner describes the relationship between the three types of debt this way:
“The code-and-component-level technical debt is usually the easiest type of debt to measure and pay down. At the same time, the architectural-level debt has a much higher impact on overall product quality, feature delivery lead time and other metrics.”
Benefits of Effective Technical Debt Management
Companies benefit by effectively managing their technical debt in two ways: by avoiding damage caused by technical debt disasters, and by improvements in their ability to innovate. Let’s take a closer look.
Avoiding Technical Debt Disasters
During the holiday season of 2022, Southwest Airlines was forced to cancel almost 17,000 flights due to the failure of its outdated flight and crew scheduling system. This outage, caused by what devops.com calls the airline’s “shameful technical debt,” has so far cost the company more than $1 billion. And Southwest isn’t alone. According to the Consortium for Information and Software Quality, poor software quality is now costing U.S. companies more than $2.41 trillion.
Improving Innovation
Technical debt is the #1 obstacle to the ability of companies to create the new technologies and products that are critical for outpacing their competition in today’s rapidly evolving marketplace. Gartner estimates that by 2025 companies will spend 40% of their IT budgets on maintaining technical debt rather than on innovation. On the other hand, a report by McKinsey declares that companies that actively manage their technical debt can free up their engineers to spend up to 50% more of their time on innovations that support the organization’s business goals.
A Process for Addressing Technical Debt
Technical debt is not just an IT issue. Rather, it’s a critical concern that affects the entire business. That fact presents software architects and developers with a unique opportunity to take on a more strategic role, first by helping decision-makers understand both the risks to the organization of failing to address technical debt and the ROI of proactively doing so, and then by providing a sustainable solution.
Building a compelling case for dealing with technical debt requires a data-driven approach that highlights its impact on important business metrics. Here’s a three-step process for doing that.
1. Measure and Track Technical Debt: Architectural Observability
As management guru Peter Drucker once famously said, “You can’t improve what you don’t measure.” That’s why the first step in the process is to begin using architectural observability for continuously measuring and tracking technical debt as a key business metric.
Related: How to Measure Technical Debt for Effective App Modernization Planning
In a 2012 paper entitled, “In Search of a Metric for Managing Architectural Technical Debt” researchers described a methodology for measuring technical debt based on dependencies between architectural elements in the code. Their approach, which has become the basis for the practical use of machine learning to measure technical debt, enabled the development of an overall technical debt score based on three key metrics:
- Complexity — the amount of effort required to add new features to the app.
- Risk — the probability that adding new features may disrupt the operation of existing ones.
- Overall Debt — how much additional work will be required when adding new features to the app.
These metrics allow you to quantify both the risks of failing to address technical debt and the expected costs of doing so.
2. Identify and Rank Apps Impacted by Technical Debt
Most companies don’t need to address technical debt in all their apps at once. Instead, it’s best to assess technical debt across the company’s legacy app estate to identify which should be modernized and in what order. The use of an automated machine learning platform for this task is crucial since any effort to manually generate accurate technical debt metrics for perhaps thousands of legacy apps is simply not practical for most organizations.
3. Build a Business Plan for Addressing Technical Debt
For enterprise architects, the biggest obstacle to effectively managing technical debt is gathering the data to plan to build the planning, required budget and resources. Business leaders often don’t have the background to allow them to fully appreciate the technical issues associated with technical debt. But they usually are very concerned about the organization’s ability to meet its strategic business goals. That’s why it’s crucial that enterprise architects make a solid business case for prioritizing an effective, ongoing technical debt management program.
McKinsey’s technical debt report highlights what the focus of that business case should be:
“Cutting back tech debt is the key to becoming tech-forward: a company where technology is an engine for continual growth and productivity.”
Unaddressed technical debt severely hinders a company’s ability to innovate and outpace competitors in its marketplace. According to a recent report on the business costs of technical debt, developers are wasting between 23% and 42% of their time because of technical debt. That contrasts with McKinley’s declaration that companies that handle their technical debt can give their engineers 50% more time to spend on solutions that help the organization achieve its strategic goals. Gartner adds that companies that effectively manage their technical debt can deliver services and solutions at least 50% faster.
Building a Data-Driven Enterprise Tech Debt Plan
Most business leaders look for hard data to drive their decisions. That’s why it’s critical that you base your technical debt business case on objective metrics. How can those metrics be produced?
The quickest and most accurate means of generating that data is by using an advanced machine-learning assessment platform such as the one provided by vFunction. The vFunction Assessment Hub is specifically designed to deliver relevant and accurate technical debt metrics. Not only does it measure the complexity and risk level of your current legacy app portfolio, but it also quantifies the benefits to be gained by refactoring the apps with the greatest technical debt burden into a cloud-native microservices architecture.
If you’d like to see first-hand how vFunction can help you modernize your legacy apps and eliminate technical debt, please schedule a demo.
