How to track — and measure — technical debt
Technology projects involve countless options for the most effective result. But the best options are not always desirable, or even possible, when a project is carried out.
Sometimes software and IT infrastructure development projects require leaders to lower boundaries, slow down features or functionality, or live with suboptimal performance to get a project off the ground. It’s the notion of “build now and fix it later.” The technical debt describes the financial and material costs involved in its subsequent repair.
Technical debt can be insidiously difficult to find, measure, and track. Forgotten commitments can quickly become long-term burdens. Companies need to control technical debt before it affects the organization’s ability to compete, or even operate.
Technical debt challenges
Consider a legacy software application running on a dedicated hardware platform, such as an older server with a specific processor type. The platform is critical to the business, but the company decides to give up software upgrades that would add competitive features and allow the workload to run on the latest hardware or virtual machines. One day, the server crashes. The company does not have the right hardware for a critical workload and has to 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 much more subtle and pervasive places. Consider the following scenarios:
- A project does not have clarity in the established definitions or requirements. The finished project requires changes and rework due to added definitions and requirements or last minute changes.
- Poor style. The code has no standards, or the equipment installs and configures the hardware without proper port and cable markings, making subsequent changes or services problematic.
- Inappropriate or omitted evidence. Software features and functions may contain defects that require later patches and fixes.
- Improper configuration. Ignoring hardware settings can affect performance and lead to security vulnerabilities.
- Inadequate documentation. Improperly documented hardware or software forces teams to relearn or rediscover their work. This extra effort is technical debt.
- Little collaboration. Silos are known for technical debt, which is incurred as multiple parallel efforts reconcile and merge.
- Business pressures drive commitments to complete or launch a project before it is ready. The result is incomplete or malfunctions and requires further corrections.
- Delays in updates. Refactoring old code improves performance and interoperability. Delaying these updates and enhancements generates technical debt.
- Errors. Defects represent a technical debt because each one requires time and effort to fix them.
- Tightly coupled and non-modular code. The code has no flexibility and can quickly generate technical debt when changes or adaptations are needed to meet changing business needs.
How to measure technical debt
Technical debt is the list of tasks that engineers or developers must perform to complete or fix a project. As the to-do list gets longer, the technical debt increases and the total time spent servicing that technical debt, called interest on technical debt – rises to the point where a project is essentially irreparable.
But organizations can use a number of metrics, such as the following, to look at technical debt from a more objective perspective:
- Defect relations. Software developers can use an account or a proportion of new defects versus old defects. For example, if there are few new defects and a significant number of defects fixed, the ratio is small, and so is the related technical debt. If new defects begin to outnumber solutions, technical debt is growing for defect management and leaders should address the problem.
- Code quality. To quantify code complexity and quality, use cyclomatic and cognitive complexity, lines of code, maintainability, inheritance depth, afferent (inner) and efferent (outer) couplings, nesting depth, and time when writing lines of code. Decreasing quality metrics are a common sign of rising technical debt. Development teams that use coding standards and strive for quality code can mitigate technical debt.
- Completion time. Please note the amount of time it takes to complete incident entries, especially low-priority ones. If engineers and developers spend a lot of time doing relatively easy tasks, it may be a sign of code or infrastructure issues. For example, if an engineer needs 45 minutes to move a cable from one port to another because the cables are not properly marked, this is a technical debt sign of the infrastructure.
- Rework or beat. This is the number of times an infrastructure task or code segment requires changes or reworking. Rework is common in new projects or assemblies, but should drop to almost zero over time. If engineers are reworking the infrastructure or code in production, they are likely to be dealing with technical debt.
- Technical debt ratio (TDR). This metric estimates the future cost of technical debt. The relationship is a simple relationship that compares how much it costs to fix problems with the total cost of building the project. While cost involves money, it expresses other resources, such as working hours. An ideal TDR works around 5%. Significantly higher ratios can be a serious problem for the business.
Technical debt monitoring
Understanding the risks and challenges of technical debt is not enough. Organizations must also set a goal to record and track it.
A common approach is to create a debt record, list, or technical document that identifies problems, explains the consequences or resulting problems, and suggests resources, such as time and cost, to solve the problem. Some organizations may link a technical debt record to the project roadmap to identify future features and functionalities that will benefit from resolving each issue.
Any technical debt list or record will also include categorization. Some organizations classify problems in terms of type or complexity, such as code debt, architectural or design debt, infrastructure debt, and test debt. Others list problems in terms of severity or priority, similar to conventional error tracking models. Technical debt issues should be classified 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 correct software defects – use a tracking system or ticket. This approach lists and prioritizes technical debt issues along with defaults, effectively keeping technical debt issues on the same page as software defects or issues.
Consider some examples of categorizing minor and critical technical debt:
- A software project uses an older API when a newer option is available but is not yet ready to implement it. The technical debt is to update the software to the latest API, which is a simple upgrade that computers can address, perhaps along with regular releases or bug fixes.
- In comparison, we assume that a software project must evolve a traditional monolithic application into a microservices application for deployment and cloud scalability. Such a large technical debt can require many steps or phases because it affects the fundamental design and architecture of the project.
Not all technical debts are the same and organizations can apply a variety of means to list and classify problems to solve them. Fortunately, there are tools available to help.
Tools to manage technical debt
Help entry systems are a common indicator and resource for identifying potential problems. But there are many tools that help measure and manage technical debt, especially in software development projects. Here are some examples of popular tools:
- Jira oversees the backlog of a project management workflow.
- SonarQube measures and improves code quality.
- Stepsize keeps track of code base issues.
- Teamscale measures and improves code quality.
- Code Climate Velocity improves workflows and allocates resources.
Most tools are integrated into the software development toolkit and provide features and functions beyond technical debt indications. Try out potential tools and gain experience before making an investment.