As a Chief Information Officer (CIO) or Chief Technology Officer (CTO), you and your team may have spent weeks, if not months, every year measuring the technical debt of your legacy applications and infrastructure. You’ve examined aging frameworks, software defect patterns, code quality, release frequencies, and technical debt ratios. You’ve presented the data to other executives. You’ve even explained the modernization process to the company’s Board. When it comes time to approve the process, everyone hesitates.
The CEO understands that maintenance costs will increase the older the technology becomes. The Board knows that legacy-system programmers are hard to find. They realize that the old technology will eventually reach its end of life if it hasn’t already. The decision-makers weigh that information against the cost of modernization, the potential operational disruption, and the lost productivity as the migration occurs — and decide to wait.
Sound familiar? Failing to receive approval can be disheartening after investing significant resources in trying to measure technical debt. However, the effort isn’t a total loss. The data can be used to demonstrate the opportunity costs of inaction. After all, business leaders understand the concept of lost opportunities.
Business executives know that reducing financial debt frees funds for investing in new markets or launching new products. Paying off technical debt is no different. With less technical debt, organizations will have the agility to take advantage of future opportunities. They can pivot quickly when unexpected events change the economic landscape. Unfortunately, developers rarely make technical decisions or justify modernization in terms of opportunity costs.
What Are Opportunity Costs When Measuring Technical Debt?
Opportunity cost in economics is the value of the next-best alternative when a decision is made. It represents what is lost when one option is chosen over another. People make either/or decisions every day, most without thinking of the opportunity costs.
For example, you spend $10.00 on a cup of coffee on your way to work (even if the walk is from one room in your house to another). The explicit opportunity cost is what else you could have purchased with the $10.00. But opportunity costs have an implicit cost as well.
Suppose you could use the money to buy ice cream for yourself and your child. The experience of buying and eating the ice cream together strengthens your relationship. How do you place a price on the experience? Quantifying implicit costs is difficult, if not impossible. However, it can be an essential intangible that can guide a decision.
When developers do not consider opportunity costs, they make decisions that often lead to technical debt that prevents organizations from achieving their business goals. Let’s look at how opportunity costs become technical debt.
How Opportunity Costs Become Technical Debt
Technical debt is the opportunity cost of a prior decision. Most development projects start with three variables — time, cost, and quality. The shorter the timeline, the higher the cost and the lower the quality. Limited resources (costs) can impact the quality and timeliness of the deliverable. Higher quality usually requires more time and money.
When choosing a variable, most project managers or developers know which variable to select, given the circumstances. If the software delivery is late, the option is coding a solution that doesn’t lengthen the timeline. What doesn’t happen is assessing the opportunity costs of what wasn’t selected. Those neglected opportunity costs can turn into technical debt.
Let’s assume that a legacy system has a series of configuration files except for one module. That module has the data in a table. No one knows why, but they assume other priorities got in the way. Years later, the table needs to be addressed because new data needs to be added. Turning the table into a configuration file is the explicit cost that wasn’t calculated when the decision was made to leave the table alone.
Using Opportunity Costs to Reshape the Technical Debt Discussion
Whether modernizing legacy systems or reducing technical debt, the goal is to replace or remove code that inhibits an organization’s ability to achieve business goals. As part of the process, it’s assumed that past methods would be revised to create a system that minimizes technical debt.
Modernization does not always lead to reduced technical debt. According to McKinsey, 20% to 40% of a company’s technology landscape is absorbed by technical debt. IT departments discuss agile development methods but fail to implement practices to minimize debt. They rush to meet sprint deadlines and opt for solutions that increase technical debt. If the debt is not addressed in a later iteration, it continues to grow.
Calculating Technical Debt
The first step in determining opportunity costs is calculating the cost to remove the technical debt. Several methods exist for calculating technical debt, including the following:
- Code Quality. Look at lines of code, nesting depth, cognitive complexity, maintainability, and similar metrics to measure technical debt. If quality metrics begin to slip, the technical debt will increase.
- Defect ratios. Compare the number of new defects against fixed defects. A high ratio indicates a growing technical debt, while a small ratio indicates little debt.
- Reworking. Stable code should require minimal upkeep. Tracking which modules or code segments are being reworked is one way to assess technical debt. If code segments require repeated reworking, the code may be contributing to technical debt.
- Completion time. Low-priority fixes should not consume significant resources. When developers take longer than expected to address a defect, the code may increase technical debt. Tracking time to complete can identify possible errors of technical debt.
- Technical Debt Ratio. Calculate the cost of addressing technical debt by comparing what it costs to fix a problem versus rewriting it.
- Automated Tools. AI-based tools can help identify and quantify technical debt. Using algorithms, the tools can provide an objective assessment of technical debt.
Because measuring technical debt can be time-consuming, AI-based tools that learn as they analyze legacy code can streamline the process. With a less labor-intensive approach, IT departments can spend more time evaluating opportunity costs without sacrificing the detailed analysis of technical debt.
Related: Evolving Toward Modern-Day Goals with Continuous Modernization
Determining Opportunity Costs
Let’s assume that the technical debt for a transaction processing module is $1 million. The module is a core component of the back office that most people view as having minimal impact on customer-facing improvements. When assessing the pros and cons of the modernization project, cost reduction seems to be the primary reason for approval.
Rather than focus on lowering costs when asking for approval, focus on opportunity costs if no action is taken.
Let’s use the transaction processing module. The existing code lacks flexibility, and adding a new transaction type would require rewriting the module. Now let’s assume peer-to-peer transfers will be a new transaction type within two years.
The government may begin regulating peer-to-peer (P2P) payments, which the existing system cannot support. Recent research indicates that 84% of the population has used P2P transfers and that about half of those use the service at least once weekly. Given the US adult population was almost 260 million in 2020, a potential market share of even 5% would equal 13 million people. Assuming 13 million people follow the research, 5.5 million would use a P2P transfer weekly. If the transaction fee were $0.05 per transaction, the lost transaction revenue — i.e. the opportunity costs — for one year would be almost $15 million.
Suddenly, the discussion isn’t about how much modernizing the module will cost but how much revenue would be lost if it isn’t.
Communicating the Opportunity Costs of Technical Debt
Customers and competitors have forced companies to modernize applications that impact customer experience. Organizations have spent millions on digital transformation without touching the core systems at the heart of their infrastructure. If the legacy systems are working, why risk breaking them?
Executives remember the chaos of past system upgrades or replacements. They hesitate to touch core systems because they fear a repeat experience. They do not see the constraints a legacy system places on their ability to pivot quickly, gain data-based insights, deliver better customer experiences, and ensure sustainability.
It’s Not Just a Technical Problem
Removing technical debt is a business problem. Yet, most businesses view it as technical. IT must change the perception if they want approval to modernize core systems. They must still conduct their due diligence to quantify technical debt and the cost to rewrite, remove, or refactor code. But they must present the information in business terms.
Using opportunity costs as a framework for presenting a business case reshapes the discussion. This effort requires a collaborative approach using subject matter experts (SMEs) who can help identify possible opportunity costs. In most cases, the SMEs know the system limitations but lack the technical knowledge to quantify the scope and cost of the effort.
Together, cross-functional teams can prepare business cases that illustrate the need for modernization beyond cost reduction. They can communicate solutions through opportunity costs that resonate with company executives. Combining resources makes reshaping the discussion possible and the chance of approval much higher.
Use the Right Tools to Start Modernizing the Smart Way
vFunction offers AI-based tools to assess the technical debt of Java and .NET applications. Using vFunction’s Assessment and Modernization Hubs, IT executives can provide a comprehensive analysis of technical debt that forms the basis for an opportunity cost assessment. Contact us to learn how our solution can help reshape your technical debt discussions.
