Technical debt: How to measure and manage it with DevOps

Every development team in the software industry is familiar with technical debt. Why? Because every software team incurs technical debt throughout the software development cycle.

Technical debt refers to the implied cost of additional rework caused by choosing an easy solution now instead of using a better approach that would take longer. There are many reasons a team might choose to take on tech debt, from time and budget pressures to headcount or skill limitations.

This article answers some critical questions about technical debt. It reviews what technical debt is and what its causes are, how it accumulates over time, and why it is essential to address it. It also questions whether technical debt is always a bad thing, explores how it is measured, and highlights how to manage it with DevOps.

What is technical debt?

When a technical team implements a sub-optimal solution to a problem, they are making a trade-off between paying the cost now to implement the optimal solution versus paying it later. In choosing to implement an expedient, short-term solution over a more durable and robust one, the team incurs a technical “debt.”

The larger the project, the more technical debt the team takes on. And, like financial debt, technical debt accrues “interest.” As the project grows, it becomes more challenging and expensive to address problems due to lost knowledge and the extensive changes required to manage the debt. Dealing with debt early is always cheaper.

While most technical debt is detectable by an experienced technical team, some debts can escape notice. Unfortunately, these hidden debts often cost more to fix than the detectable ones.

Having a DevOps process can slow down the accumulation of technical debt through early detection, quality control, and building organizational support for addressing technical deficits.

What causes technical debt?

There are two primary causes of technical debt:

1. Business requirements including time pressure and changing conditions

2. Technical leadership problems such as poor design or flawed review processes, tools, documentation, and test suites

Some debt may also come from insufficient support from the business to address technical debt itself.

Why is technical debt important to address?

Simply put, technical debt is expensive to fix if left alone. And, the cost comes in various forms, like:

• Features take longer to develop

• Product quality suffers

• Company reputation takes a hit

To show how technical debt grows, imagine a development team is working on a product without DevOps. It could be that they did not have the time to introduce DevOps, or maybe they did not have the budget. It could be that they did not think it was going to make enough of an impact.

When they introduce new code, a developer on the team tests it on their computer and pushes it to the QA environment. Deploying code can be simple, but it is also error-prone. Errors happen when someone deploys outdated code, sends correct code to the wrong server, or pushes uncommitted code. The added time it takes to diagnose these issues is the “interest” that accrues when teams do not have DevOps procedures.

Sometimes the disruption is minimal, and there is little awareness in the rest of the organization. Other times, such errors can bring the entire environment down, impacting everyone involved. At the minimum, somebody wasted their time re-executing their test, costing the company by extending development time.

Technical debt costs money, and businesses need to understand how technical debt accumulates. Only then can they support the technical teams who need to address the debt.

How does technical debt accumulate?

In general, technical debt accumulates as a direct result of time pressure. When racing to meet a delivery date, it is often an easy call to leave some lower priority bugs to the end. This group of issues, for many teams, becomes a “bug graveyard.”

At the same time, it is tempting to address higher priority issues using quick and easy fixes. You may intend to return and work on them later, but the number of those “TODOs” in the code can start growing quickly.

In practice, a TODO in the code will stay undone because if you’re already in a time crunch you will likely struggle to find more time later. And, as time goes by, the context of the issues is forgotten, they become more time-consuming to address, and people become less inclined to take them on.

To save time, development teams may find quick-fix solutions that speed delivery instead of taking the time to refactor. Over time, they find that the cost of maintaining these ad-hoc solutions far exceeds the cost of paying back the debt. Then they may decide to refactor the code. In some extreme cases, this may lead to a complete product rewrite.

Sometimes, teams can unknowingly incur technical debt because they lack the knowledge or skill to write better code. As a result, the code becomes harder to maintain as the codebase grows.

Technical debt is inevitable regardless of the team’s makeup or the company. Your development teams must manage and pay back tech debt regularly. DevOps can provide the guidelines and tools to make this possible.

Is technical debt always bad?

Tech debt can be expensive, but you don’t have to repay it all right away. Like a business taking on financial debt to grow, taking on an appropriate amount of technical debt can be healthy. In other words, don’t let perfection become the enemy of the good.

If the cost of addressing an issue in the future is less than the value of taking on the debt, it makes sense to take on that debt. However, if left alone, technical debt can become unmanageable, eroding the foundation of the codebase. So, it is crucial to manage the debt. And to manage tech debt, you must measure first.

How is technical debt measured?

Measuring technical debt can be complex, and there are many variables to consider. The team’s composition changes, technology changes, and even requirements change. Minimize the effect of these variables using a ratio.

Technical debt ratio

Technical debt ratio (TDR) is the ratio of the cost to fix the codebase compared to building it. Organizations can measure the price in either time or monetary value.

Using a ratio can be helpful when getting support from the business. That support may be relaxing the timeline, increasing the budget, reducing the number of “must-have” features, or providing training and tools for the teams.

You can use the TDR to show executives and stakeholders that paying back a particular technical debt has more value than letting it grow. It can be an organizational goal to keep the TDR below a set threshold.

Automated tooling for analyzing technical debt in code

Manual estimates can be inconsistent and subjective, so they are less trustworthy from a business perspective. Using code scanners like SonarQube and Kiuwan can eliminate that concern. For example, SonarQube scans the entire codebase and objectively estimates how long it would take to address any issue it finds.

It is beneficial to combine tools like these with DevOps best practices.

How to manage technical debt with DevOps

Although DevOps can’t solve every tech debt issue, it does enhance team communication, and early detection of issues can reduce the number of bugs in the code.

Tools like SonarQube and Kiuwan strengthen your CI/CD pipeline by continuously calculating tech debt and reporting on it.

DevOps can serve as a communication tool between the technical team and the company. It can also be used as an educational tool to inform developers about the kind of code that can introduce bugs in the future. This knowledge should raise code quality and reduce the number of bugs.

Lack of DevOps standards is a technical debt that companies must pay. With well-defined DevOps standards, it is possible to create quality gates on each code check-in, run tests, then deploy. This approach saves developers from repetitive and error-prone manual operations and optimizes development effort. Indirectly, this saves the company money by keeping morale high and maintaining a high level of productivity.

Finally, DevOps also enables continuous delivery. With continuous delivery, you push features as they are developed. Continuous delivery minimizes the barrier to refactoring, by making it easier to catch issues quickly when there are more frequent releases.

Conclusion

Throwing together a suboptimal solution may save time in the short term, but the tech debt it can incur will grow. This debt accrues interest, or adverse consequences, until the team pays it off by implementing an optimized, sustainable solution. It is not always necessary to repay technical debt right away. However, it is vital to manage technical debt and make sure it stays below a maintainable threshold.

DevOps plays an essential role in managing technical debt. Integrating tools like SonarQube and Kiuwan into your CI/CD pipeline can help you detect suboptimal code early, reducing the number of bugs and communicating up-to-date results to the whole team.

To get a handle on your technical debt before it spirals out of control, try CircleCI today and see how it can help you maintain a healthy balance between development velocity and code quality.

Start Building for Free