Most companies carry technical debt, costing them 20% to 40% of their technology’s value. Over 60% of chief information officers believe their technical debt will continue to grow. Some suggest the debt adds 20% to 30% to the cost of any development project. Yet, there’s no consensus as to what equals too much debt.
Some suggest a percentage—less than 10% or never more than 20%. Others assess debt based on its impact on velocity, innovation, cost, or system maintenance. There’s even an approach using the 80/20 rule. Applying 20% of a team’s time will address 80% of the problems – most often the low-hanging fruit. The last 20% will take 80% of their time, but for most organizations that’s the most critical component impacting their business. Deciding on what to do with the heavy 20% requires developing a strategy on how to prioritize tech debt.
How to Prioritize Tech Debt: Begin with Assessment
Prioritizing debt means quantifying it. How much debt is there? What type of debt exists? Is there legacy code? What about dead code? How badly is it affecting business velocity and innovation? Knowing the type and amount of debt is the first step in prioritization.
Assess the Technical Debt
Before setting priorities, organizations need to know their current technical debt situation. They can calculate technical debt using defect or technical debt ratios. They can evaluate code quality or the time to complete maintenance tasks. Here are five examples of how IT departments calculate debt.
- Architectural technical debt. While this is the most difficult to to calculate, it is the most important to track as it involves the accumulation of architectural decisions and implementations that lead to high complexity of software manifested in slow engineering velocity, diminished innovation and limited scalability.
- Defect ratios. Software development tracks the number of new versus fixed defects. If new defects are reported faster than developers can address them, the ratio is higher, indicating a growing technical debt.
- Technical debt ratios (TDRs). TDRs estimate the potential cost of technical debt. Organizations compare the cost of fixing a problem, such as a legacy application, versus the cost of building a new application.
- Code quality. This involves identifying quality metrics such as lines of code, inheritance debt, and tight couplings to quantity code quality and complexity. Coding standards can be used to help control code quality.
- Rework. As code matures, the amount of rework should decline. If architects and engineers are redoing production or infrastructure code, it is most likely the result of technical debt.
Automated tools make the process less cumbersome; however, the solutions vary significantly. When looking at tools, make sure the solution fits the development environment, offers observability, and supports continuous modernization.
Establish a Baseline
As noted above, McKinsey found that companies pay 10% to 20% more per project to address technical debt. About 30% of chief information officers (CIOs) said that 20% of their new product development budget is used to resolve technical debt issues. Setting a baseline helps channel efforts toward sustaining an acceptable level of tech debt.
Related: Technical Debt: Who’s Responsible?
Initial assessments identify the current level of technical debt, but a baseline should establish an ongoing target. Deciding on the optimum baseline requires more than picking a number. It requires a management strategy that prioritizes debt to minimize risk, encourage innovation, and deliver efficiencies.
Set Priorities
Reducing debt is not just a technical decision. Business objectives play a role in setting priorities. While developers may focus on eliminating debt that keeps them from working on new features, executives may want to lower the risk of operational failure. At the same time, executives may focus on replacement costs rather than the resources lost to maintaining an aging system.
As IT departments evaluate how to prioritize tech debt, they must prioritize troublesome areas according to operational risk, maintenance requirements, and innovating capabilities. Breaking down code into these three groups helps identify the potential business impact of tech debt. It also simplifies the process of assigning technical priorities.
Operational Risk
Two words can summarize the importance of operational risk when setting priorities: Southwest Airlines. Despite employee warnings, the company chose to ignore its growing technical debt until the perfect storm hit during the 2022 holidays. The results were almost 17,000 canceled flights, disgruntled employees, and declining customer trust. The company estimated the outage cost them $825 million.
Legacy software also poses a security risk. Whether third-party libraries or unsupported software, old code presents security vulnerabilities. It often does not support recommended security practices such as multi-factor authentication (MFA). Known vulnerabilities can be exploited as hackers comb the internet for specific applications.
Maintenance
Inflexible codebases and complex systems increase the time needed to address customer issues. A time-out when running a report can take hours—time needed to isolate the source, understand the code, and test the fix. Faster deployment systems do not work with older code, and delivery can take another day. What should have taken four hours at the most consumes two days of a developer’s time.
Some teams allocate 25% of their workweek to addressing technical debt. They make it part of everyone’s workload. However, successful implementation requires a system to ensure the time is being used appropriately. Pressure to deliver new features or fix an “immediate” problem can easily take time away from removing technical debt.
Innovation
Inefficient tools and processes add to the time developers spend on non coding tasks. Those minutes quickly turn into hours, leaving less time for innovating new product features. Tech debt can mean infrastructure and applications that cannot support newer technology.
With high technical debt, organizations may lack the agility to deploy the latest technology. For example, big data analytics and artificial intelligence (AI) rely on the cloud for processing power. Companies looking to implement these new technologies will want solutions that work seamlessly with the cloud.
Define a Technical Debt Management Strategy
One of the biggest obstacles to removing technical debt is time. There’s never enough to simultaneously reduce debt, maintain current code, and develop new features. Unless there’s a clear strategy with established priorities, departments can find themselves adding to instead of removing tech debt. An effective management strategy acknowledges that removing technical debt is a continuous process.
Adopt Continuous Modernization
Continuous modernization uses incremental improvements in an iterative process to deliver software changes. The process minimizes risk while increasing value. Projects are smaller, allowing for greater agility and faster feedback.
With a continuous modernization model, organizations resolve technical debt in steps. By establishing business-aligned priorities, code changes can be ranked according to complexity, resource availability, and time. For example, a high-priority change is needed to protect against operational failure. However, its complexity requires significant resources. The change may rank slightly lower than expected because the resources are not available.
While waiting for resources, team members are assigned other priority changes that require fewer resources. The process ensures that the most crucial technical debt is being addressed as quickly as possible but is not preventing other improvements from being made. When it’s time to address the high-priority fix, teams can use observability tools to see how the incremental improvements are working.
Ensure Architectural Observability
A baseline enables architects to understand what changes are needed and how those changes will impact technical fitness. It allows developers to assess architectural drift. Without observability, teams struggle to see and pinpoint their architectural debt, fix it, and prevent future drift from impacting performance. Comparing baselines before and after modernization efforts helps identify whether previous were fixed and what new issues may need to be addressed.
Related: How Unchecked Technical Debt Can Result in Potential Business Catastrophe
Architectural observability will help architects and developers:
- Identify domains with dynamic analysis and AI
- Visualize class and resource dependencies and cross-domain pollution
- Pinpoint high-debt classes
- Improve modularity by adding common libraries
- Identify dead code and dead flows based on production data
Observability tools can also provide data to support business-related priorities. Tracking architectural efficiencies can highlight improvements that reduce risks. Tools also provide data on the efficacy of each change. Together, the information builds a system on how to prioritize tech debt in any environment.
Assign Ownership
Visibility only has value if someone is using it. By enabling ownership for architects and their applications, organizations can ensure that someone is observing the modernization process. With automated tools, tracing architectural drift can be as simple as setting threshold values. No one needs to pour over log files or stare at screen output to ensure that technical debt is being reduced.
Continuous modernization platforms can provide automation to manage technical debt through an iterative process. They can offer system architects the visibility they need to develop a management strategy that reflects business and technical priorities. With automated tools, ownership becomes an informative process that leads to continuous improvement rather than a burdensome task to avoid.
How to Prioritize Tech Debt Effectively
While leading the removal of tech debt may be an architect’s domain, deciding on priorities is a shared responsibility. Development teams must look at operational risks, maintenance costs, and innovation limitations when setting priorities. They must also weigh resource availability and delivery schedule to decide how to best optimize modernization efforts.
To be successful, IT departments must integrate priority-setting strategies with continuous modernization models. They need automated tools that provide the observability to ensure that tech debt is being reduced and architectural drift is contained. Automated tools enable development teams to take ownership of the modernization process. vFunction’s modernization platform enables organizations to assess and prioritize their technical debt. It helps teams manage their continuous modernization processes with observability to successfully manage architectural drift and technical debt. Contact us today to request a demo and see how the platform can work for you.
