July 6, 2018

In an ideal world, every project is finished on time, and within the estimated budget, even better the budget has allowed 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 tech debt is among the most common issues the project may face. It is essential to understand what is technical debt, how to measure technical debt and especially how to tackle it.

 

List of The Contents

WHAT IS TECHNICAL DEBT?

Technical debt is the additional work needed to complete software development. But this notion does not refer solely to the projects that are in development. This issue often follows the projects that are in production for some time. This may be anything, like some module written on the legacy technology, that holds the project back from including a new functionality or influence overall software stability. In this particular case, it 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 software system includes a number of the drawbacks that can be included in the tech debt of the project.

Not addressing these debts as soon as possible can lead to others in the future resulting in poor software performance, difficulty or even impossibility to bring 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 is a reference borrowed from the finance world, like financial or tech debts, if they are not resolved very quickly, it can generate interest. In other words, it can give rise to new tech debts and can cost a lot to the software owner and development team.

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

WHAT CAUSES TECH DEBTS

To better address this topic, it is essential to understand what caused them in the first place. There are four major reasons: 

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, and development is mainly focusing on developing 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: Underestimation during the software development estimation process often causes tech debt. The 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 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 over and over the same logic and format their codes the way they want rather than the way it is commonly accepted in the particular software project.

OUTDATED TECHNOLOGY: As technology evolve, and software standard becomes higher every day. With each improvement, new tech debt can arise.

Now that we have more understanding of what is technical debt and how do we get it in our projects. Let’s see ways for measuring technical debt.

TYPES OF TECHNICAL DEBT

We have previously explored what is technical debt. This is important for measuring technical debt accurately as the estimation depends on their 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 tech debts 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 codes sometimes serve different business logic. The more codes developers write, the more lack of modularity can be a bottleneck. It is harder to manage the 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, 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 debt let’s see how to estimate them.

HOW TO MEASURE TECHNICAL DEBT

Now that we have reviewed the types of technical debt, it is crucial to find the right approach on how to measure technical debt. In no way, it should be calculated manually since doing so will require going into the code and detect all issues inside and then estimating all possible issues 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:

There are two ways to measure technical debt. The first one is to get a ratio according to code volume, the second one is to use directly the estimates given by the tools (like SonarQube), along with the list of tech debts and their references to the codes, SonarQube gives an estimate in days or hours needed to fix these debts. 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 approximate of the time needed to fix it. Fixing tech debts costs money, it would take additional man-days from the development team to fix them. The more tech debts there are to be fixed, the more time the development team would need to fix them. Leaving them inside code is not an option, tech debts, if left uncorrected, will lead to more tech debts that would make future changes more and more difficult. Even though the attempt to reduce technical debt can be costly, not addressing them earlier stage will cost more money in the future.

HOW TO REDUCE TECHNICAL DEBT

Being Agile is the best way of managing technical debt and reducing them when they appear. The sooner we address the issue, the less interest is going to pay over time. The software development team can use the following approach.

THE QUICKEST TO SOLVE: fixing debts that take little time to fix is an excellent way to eliminate tech 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 tech debts, 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 on how to reduce technical debt, but how to handle technical debt in agile? Since resolving this issue is a continuous goal the development team should aim at, they 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 tech debts 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 tech debts at some point in 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 tech debts, 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 technical debt measurement is based on existing codes that often evolve. It is then necessary to have a good approach on how to calculate 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 estimates.

Although addressing tech debts can cost money, leaving it in the software will cost more money in the future.

What is your favorite approach to tech debt management and why? Leave your thoughts and questions in the comments section below. Need a hand with the refactoring old code, porting your legacy application to the new trendy technology or anything related to the effective elimination of the technical debts in your project? We can help. Existek is an offshore software development company with extensive experience in consulting and project rescue. We can quickly assemble the dedicate development team for your project which will gradually analyze your solution, test it, come up with the solution, and bring it to perfection to make it ready for the introduction of new features and improvements. Contact us via the form at the website or start the discussion in the chat to get a free consultation on your case!