What Technical Debt Is and How to Calculate It

In an ideal world, every project is finished on time, and within the estimated budget. Even better, the budget has allowed teams to develop additional features and test everything one more time before the release. In the real world, the development process can encounter several difficulties, and technical debt is among the most common issues the project may face. It is essential to understand what technical debt is, how to evaluate it and especially how to tackle it.

What Is Technical Debt?

Technical debt is the additional work needed to complete the software development. But this notion does not refer solely to the projects that are in development. This issue often follows the projects that have been production for some time. This may be anything, like some module written on legacy technology, that holds the project back from including a new functionality or influence overall software stability. In this particular case, technical debt can be calculated as the time or money needed for the refactoring of this module's code or porting it to the new technology. But usually it is never that simple and the software system includes a number of drawbacks that can be included in the technical debt of the project.

Not addressing these debts as soon as possible can lead to more debts in the future, resulting in poor software performance, difficulty or even impossibility in bringing change to the software, an increased risk of breaking the software after each update. Managing technical debt at an early stage of the development process is crucial.

The use of the term debt is a reference borrowed from the finance world, and like financial debts, technical debts, if they are not resolved very quickly, can generate interest. In other words, technical debt can give rise to new technical debts and can cost a lot to the software owner and development team.

Now that we know what technical debt is, how do we get it?

What Causes Technical Debt?

To better address technical debt, it is essential to understand what caused them in the first place. Four major reasons lead to technical debt:

• Poor Conception: When developing an application, the speed at which the team or the company delivers the product can make a real difference, after all, an application or software is developed to answer a particular problem or to address a specific challenge in a timely manner. It is important to use the product when the need is still there. The rush in delivering faster often results in poorly designed software. The software product is not well thought out, and development is mainly focusing on developing the functionalities. There can be a prior agreement at the beginning of the project between the product owners and the development team to launch the first features faster and allocate time to correct later on to reduce time to market.

• Poor Scheduling: Underestimating during the software development estimation process often causes technical debt. A development team's focus is on the respect of time estimates and is accumulating lots of bad practices that they will ultimately have to pay.

• Bad Development Practices: It is crucial that the development team has a set of practices and conventions so that there is a little or no significant difference in design and implementation from feature to feature. A lack of development good practices and conventions will lead developers to implement their design, rebuild the same logic over and over, and format their code the way they want rather than the way it is commonly accepted in the particular software project.

• Outdated Technology: As technology evolves, software standards become higher every day. With each improvement, new technical debt can arise.

Now that we have more understanding of what technical debt is and how we get technical debt in our projects, let's see ways for measuring technical debt.

Types of Technical Debt

We have explored what technical debt is. This is important for measuring technical debt accurately as the estimation of technical debt depends on its nature. The most common types of technical debt are:

• Source Code Formatting: This is very common, but fortunately, this is the easiest to fix. Using the right tool and template during and even better before starting the development process can reduce this kind of technical debt dramatically.
• Low Test Coverage: Test coverage is an essential measure of code quality, especially when we use Agile methodology to support the development process. Tests ensure that each part of the code is behaving the intended way. A very low level of the test coverage reduces the certainty of the accuracy of the software's behavior and makes it difficult to solve problems when they occur.
• Lack of Modularity: This generally results from a poor code design. Some code sometimes serves different business logic. The more codes developers write, the more lack of modularity can bottleneck. It is harder to manage software that has logics all over the codes and have parts of codes handling several logics.
• Code Complexity: Complexity can be measured in several different ways, but it measures the dependence and path length to perform an operation. A long path leads to complex code.
• Lack of the Documentation: Documentation is part of software development best practices. The software is often driven to evolve. It is important that the written code is always understood at all times by everyone who may be involved in the development process.

Now that we have identified the types of technical debts, let's see how to estimate them.

Technical Debt Estimation

Now that we have seen what technical debt is and have reviewed the types of technical debts, it is crucial to find the right approach for measuring technical debt. In no way should it be calculated manually since doing so will require going into the code and detecting all issues inside and then estimating each possible issue one by one. It is not only time-consuming to proceed that way, but it is almost impossible to estimate evolving codes. At the point when measuring technical debt is done, the codes have already a different state.

One approach is to perform a static analysis of code using tools that support the analysis. The following is a list of the most popular tools used:

• Coverity
• SonarQube
• Checkstyle
• Closure Compiler

There are two ways of measuring technical debt. The first one is to get a ratio of technical debt according to code volume, and the second one is to use directly the estimates given by the tools (like SonarQube), along with the list of technical debts and their references to the code, SonarQube gives an estimate in days or hours needed to fix this debt. For the ratio approach, we can use the initial estimates or even better, the overall time needed to develop the software so far and extrapolate the value according to the technical debt ratio. The time needed for the development is very accurate so measuring technical debt from ratio can give an accurate estimate of the work needed to fix the issues.

Measuring technical debt gives us an approximation of the time needed to fix the technical debt. Fixing technical debts costs money, and it would take additional man-days from the development team to fix them. The more technical debts there are to be fixed, the more time the development team would need to fix them. Leaving technical debts inside code is not an option, as technical debts, if left uncorrected, will lead to more technical debts that would make future changes more and more difficult. Even though the attempt to reduce technical debts can be costly, not addressing them earlier stage will cost more money in the future.

How to Reduce or Eliminate Technical Debt

Being agile is the best way of managing technical debt and reducing it when it appears. The sooner we address the issue, the less interest we'll have to pay over time. To address technical debt, software development teams can use the following approach.

• The Quickest to Solve: Fixing debts that take little time to fix is an excellent way to eliminate technical debt gradually. Debts like code formatting can be solved in a little time, making up a template and apply these templates to all the codes that have been developed so far, then integrate these templates in the tools used by the developers.

• Priority: It is also important to address issues by priority. All issues that can lead to more significant issues should be addressed quickly and should be prioritized to avoid accumulation.

• Technology Update: When outdated technology leads to technical debt, it is important to update the software to the newest versions of the frameworks, application servers, databases etc. It is even important to include every stable evolution of a framework used for instance to always have the latest update and to bring small change without breaking the software.

• Refactoring: Reviewing the software architecture and refactoring codes often can be useful when we don't want to end up with duplicate code or codes that lack modularity.

These are useful approaches to reduce or eliminate debt, but how to handle technical debt in agile processes? Since resolving technical debt is what the development team should aim for, technical debt should be entered in the product backlog as a user story and should be prioritized like any user story. The prioritization should take into account the impact of not managing technical debt identified at the beginning of a new iteration. When deciding which stories to include in the next development iteration, we should analyze whether postponing technical debt correction for the next iteration is more or less advantageous in the long term. As a rule of thumb, we should address every critical issue as soon as it is identified.

Final Thoughts

Having technical debt at some point of the software development process is quite usual. However, managing technical debt is important to avoid their accumulation over time. Sometimes, it may be required to accept a certain amount of technical debt, but ultimately there should be kept at an acceptable level at which they don't harm the performance and the overall experience of the software product users.

Contrary to the estimation of development time, the estimation of technical debt is based on existing code that often evolves. It is then necessary to have a good approach to estimate the technical debt included in the software developed. Due to the ever-shifting nature of the code and the volume of codes to be evaluated, it is not possible to perform a manual estimation. It is then necessary to work with the right tools that allow an automatic computation of technical debt estimates.

Although addressing technical debt can cost money, leaving technical debts in software will cost more money in the future.

What is your favorite approach to technical debt management and why? Leave your thoughts and questions in the comments section below.