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 technical debt is among the most common issues the project may face. It is essential to understand what is technical debt, how to evaluate them and especially how to tackle them.
List of The Contents
- What is technical debt
- What causes technical debt
- Types of technical debt
- How to estimate it
- How to eliminate technical debt
- Final thoughts
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 are in the 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, 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 software system include a number of the 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 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 debt is a reference borrowed from the finance world, 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 is technical debt, it is important how do we get it.
WHAT CAUSES TECHNICAL DEBTS
To better address technical debts, 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, 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: Underestimation during software development estimation process often causes technical debt. Development team 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 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 technical debt can arise.
Now that we have more understanding of what is technical debt and how do we get technical debt in our projects. Let’s see ways for measuring technical debt.
TYPES OF TECHNICAL DEBTS
We have previously explored what is technical debt. This is important for measuring technical debt accurately as the estimation of technical debts depends on their nature. The most common technical debts are :
SOURCE CODE FORMATING: 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 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 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 debts let’s see how to estimate them.
TECHNICAL DEBTS ESTIMATION
Now that we have seen what is technical debt and have reviewed the types of technical debts, it is crucial to find the right approach for measuring 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 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:
There are two ways for measuring technical debt. The first one is to get a ratio of technical debt according to code volume, 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 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 the technical debt. Fixing technical debts costs money, 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 development team would need to fix them. Leaving technical debts inside code is not an option, 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 debts and reducing them when they appear. The sooner we address the issue, the fewer interest is going to pay over time. To address technical debt, 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 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? Since resolving technical debt is a continuous goal the development team should aim at, technical debts 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 the postponing technical debts correction for a 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.
Having technical debt at some point of the software development process is quite usual. However, managing technical debts is important to avoid their accumulation over time. Sometimes, it may be required to accept a certain amount of technical 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 estimation of technical debts is based on existing codes that often evolve. It is then necessary to have a good approach to estimate the technical debts 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 debts 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 the technical 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 debt in your project? We can help. Existek is an offshore software development company with an 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!