Every technical team in the software industry is familiar with technical debt. That is because every software team incurs technical debt during every software development cycle.
This article answers some critical questions about technical debt. It reviews what technical debt is and what its causes are, why it is essential to address it, and how this debt accumulates. It also questions whether or not 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 doing so, this team is incurring a technical “debt.”
The larger the project is, 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 scale of change required to handle the debt. It is almost always cheaper to deal with the debt early.
While many technical debts are detectable by an experienced technical team, some still escape notice. Unfortunately, the ones that escape detection 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?
It is essential to examine the causes of technical debt to see how a DevOps process can help. There are two primary sources of technical debt:
- Business requirements including time pressure and changing conditions
- Technical leadership problems such as poor technological 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. It is a simple yet error-prone process: Someone can deploy outdated code or the correct code to the wrong server, or someone else may push uncommitted code. The time spent diagnosing such 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.
Actual dollar values are associated with technical debt, 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 bugs, for many teams, is the “bug graveyard that nobody is ever going to address.”
At the same time, it is tempting to address higher priority issues using quick and easy fixes. The intention is to go back and address them adequately in the future (just check the number of “TODOs” in the code). Realistically, they will remain things “to do” for a long time because a team already in a time crunch is unlikely to find more time down the line. And, as time goes by, developers lose the context of the issues and become less inclined to address them.
Technical decisions made earlier may no longer suit the software’s current needs. But to save time, it is common for development teams to 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. It is essential to manage and pay back the debt regularly. DevOps can play a part in achieving this.
Is technical debt always bad?
While it is true that technical debt can be expensive, it is also true that you do not have to repay all technical debt right away. Similar to a business taking on financial debt to grow, taking on an appropriate amount of technical debt can be healthy. Do not let perfection become the enemy of 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.
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 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.
How to manage technical debt with DevOps
Although DevOps cannot solve all issues around technical debt, it can slow the accumulation of that debt by early detection, which reduce the number of bugs and improves communication.
By incorporating tools such as SonarQube and Kiuwan in your CI/CD pipeline, you can continuously calculate technical debt and communicate about it to the business. 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, features are pushed 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
Technical debt is incurred by software teams that implement a suboptimal solution in the interest of saving time. 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 can play an essential role in managing technical debt by incorporating tools such as SonarQube and Kiuwan. These tools detect suboptimal code early, reducing the number of bugs and communicating up-to-date results to everyone involved.
To learn more about how CircleCI helps dev teams balance technical debt with development velocity, explore CircleCI
