How to track -- and measure -- technical debt

Technical debt challenges

Consider a legacy software application that runs on a dedicated hardware platform, such as an aging server with a specific processor type. The platform is critical to the business, yet the business decides to forego software upgrades that would add competitive features and enable the workload to run on more current hardware or VMs. One day, the server fails. The business lacks suitable hardware for a critical workload and must spend time and money to create a replacement application.

While this is an extreme example, the consequences of technical debt can be devastating. But technical debt can exist in far more subtle and pervasive places. Consider the following scenarios:

• A project lacks clarity in set definitions or requirements. The finished project requires changes and reworks because of added definitions and requirements or last-minute changes.
• Poor style. The code lacks standards, or teams install and set up hardware without proper port and cable markings, which makes later changes or services problematic.
• Inadequate or omitted testing. Software features and functions might contain flaws that require patches and fixes later.
• Inadequate configuration. Overlooking hardware settings might affect performance and lead to security vulnerabilities.
• Inadequate documentation. Hardware or software that is not documented properly forces teams to relearn or rediscover the work. This additional effort is the technical debt.
• Poor collaboration. Silos are notorious for technical debt, which incurs as multiple parallel efforts reconcile and merge.
• Business pressures drive compromises to complete or release a project before it's ready. The result is incomplete or performs poorly and requires fixes later.
• Delays in updates. Refactoring old code improves performance and interoperability. Delaying such updates and upgrades builds technical debt.
• Bugs. Defects represent technical debt because each demands time and effort to remediate.
• Closely coupled and non-modular code. The code lacks flexibility and can quickly drive technical debt when changes or adaptations are necessary to meet changing business needs.

How to measure technical debt

Technical debt is the list of tasks engineers or developers must perform to complete or fix a project. As the to-do list lengthens, technical debt increases, and the total time spent servicing that technical debt -- dubbed technical debt interest -- climbs to the point where a project is essentially irreparable.

But organizations can use a range of metrics, such as the following, to see technical debt through a more objective lens:

• Defect ratios. Software developers can use a tally or ratio of new defects versus old defects. For example, if there are few new defects and a sizable number of fixed defects, the ratio is small -- and so is the related technical debt. If the new defects begin to outnumber the fixes, technical debt is growing for defect management, and leaders should address the issue.
• Code quality. To quantify code complexity and quality, use cyclomatic and cognitive complexity, lines of code, maintainability, depth of inheritance, afferent (inward) and efferent (outward) couplings, nesting depth and time when writing code lines. Declining quality metrics are a common sign of growing technical debt. Development teams that use coding standards and strive for quality code can mitigate technical debt.
• Completion time. Consider the amount of time it takes to complete trouble tickets -- especially low-priority issues. If engineers and developers spend a lot of time doing relatively easy tasks, it can be a sign of code or infrastructure trouble. For example, if an engineer needs 45 minutes to move a cable from one port to another because the cables aren't properly marked, that's a sign of technical debt in the infrastructure.
• Rework or churn. This is the number of times that an infrastructure task or segment of code requires change or rework. Rework is common in new projects or assemblies but should fall to almost zero over time. If engineers are reworking infrastructure or code in production, they are likely dealing with technical debt.
• Technical debt ratio (TDR). This metric estimates the future cost of technical debt. The relationship is a simple ratio that compares what it costs to fix the problems against the total cost to build the project. While cost implies money, it expresses other resources, such as labor hours. An ideal TDR runs at around 5%. Significantly higher ratios can pose a serious problem for the business.

Tracking technical debt

Understanding the risks and challenges of technical debt is not enough. Organizations must establish an objective means to record and track it, too.

One common approach is to create a technical debt register, list or document that identifies the issues, explains the resulting consequences or problems, and suggests resources -- such as time and cost -- to fix the problem. Some organizations might tie a technical debt register to the project roadmap to identify future features and functionality that would benefit from resolving each issue.

Any technical debt list or registry will also include categorization. Some organizations categorize issues in terms of type or complexity, such as code debt, architectural or design debt, infrastructure debt and test debt. Others list issues in terms of severity or priority, similar to conventional bug tracking models. Technical debt issues should be categorized in terms of severity -- such as low, minor, major or critical -- and prioritized as low, medium, high or immediate.

Organizations can track technical debt issues in the same way they track and remediate software defects: Use a ticket or tracking system. This approach lists and prioritizes technical debt issues along with defects, effectively keeping technical debt issues on the same page as software defects or problems.

Consider some examples of minor and critical technical debt categorization:

• A software project uses an older API when a newer option is available but not yet ready to implement. The technical debt is to update the software to the newest API, which is a straightforward update teams can address -- perhaps along with regular releases or bug fixes.
• By comparison, suppose a software project needs to evolve a traditional monolithic application into a microservices application for cloud deployments and scalability. Such a sweeping technical debt might take many steps or phases to accomplish because it affects the project's fundamental design and architecture.

All technical debt is not equal, and organizations can apply a variety of means to list and categorize issues for resolution. Fortunately, tools are readily available to assist.

Tools to manage technical debt

Help ticketing systems are a common indicator and resource to identify potential issues. But there are numerous tools that help measure and manage technical debt -- especially within software development projects. Below are a few examples of popular tools:

• Jira monitors a project's management workflow backlog.
• SonarQube measures and improves code quality.
• Stepsize tracks codebase issues.
• Teamscale measures and improves code quality.
• Code Climate Velocity improves workflows and assigns resources.

Most tools integrate within the software development toolset and provide features and functions beyond indications of technical debt. Test prospective tools and gain expertise before making an investment.