How to Evaluate, Manage, and Avoid Technical Debts
If technical debt sounds like something lifted from a handbook on finance, it is because the term is related to finance. However, in the real sense of it, technical debt is related to programming. It is the idea that during the development of a software project, certain necessary steps are skipped, or just jettisoned altogether in a bid to meet a deadline.
In a bid to develop the perfect app or software, developers are often strapped for time — just like any random person carrying out any arbitrary task anyway. Thus, it usually makes sense to have some sort of trade-off between delivering a perfect product with perfect code and maximizing time.
The question then is: is there a limit to these trade-offs? Are there inherent harms that could result from this trade-off? Finally, is the developer really better off in the long run? In this piece about technical debts, I will attempt to answer all of these questions.
What Is Technical Debt?
In defining technical debt, we will have to refer to the man credited with having generated the term in the first place: Ward Cunningham. According to Cunningham, technical debt refers to the extra developmental work that has to go into programming a code to make up for the deficit arising from programming it within a short period.
To make it more graphic, imagine you are tasked with cleaning up a messy room, and you are running late for a class. In a bid to make sure you carry out the instruction and also be on time for your class, you do a quick cleaning, sweeping most of the debris under the couch. The fallout of this is that you will eventually have to take the time sorting through the mess. For software development, when you skip through the necessary steps and follow an easier route, with ‘not so clean’ codes, it will get harder to clean up the code later in the future. There are multiple phases encountered in the software project dominoes, and the longer you ignore an existing problem, the longer it takes to get resolved.
Types of Technical Debts
Technical debts are of different types, including:
Planned Technical Debts
This occurs in situations where organizations deliberately decide to go into technical debts. This, as earlier discussed, is usually to beat stated deadlines and arrive at a specific goal. When engaging in planned technical debts, the organization needs to be clear what they are willing to give up, and what they cannot. You have to keep accurate records, bearing in mind that you’ll eventually have to return and correct the errors you skipped through in the beginning.
Unintentional Technical Debts
This type of technical debt is a direct opposite to the first. It arises when an organization does not foresee or plan for technical debt. The reason for this is typically a breakdown in communication between the various units in the organization, or lousy work practices between the units.
Unavoidable Technical Debts
This is the kind of technical debt that no action on the part of the organization could have prevented. For instance, with the rapid changes experienced in technology, it makes sense that some codes written in the past will fall short of the current standards projected.
Also, this sort of technical debt can arise when changes are requested when the code is already being written. If midway into designing the software, certain changes are introduced, it could mess up the dynamics, making the old code obsolete or unnecessary.
Causes of Technical Debt
Some of the reasons for technical debt have been discussed above, but I will just pick them out one after the other to make them clearer.
Haste
The most frequent cause of technical debt is haste. Developers often have stringent deadlines, some of which include deadlines for launching certain software. It is often understandable (and expected) in these sorts of situations that the developer might incur technical debts along the way. This type of technical debt is often intentional and may result in problems that could range from having bugs in the code, or spaghetti codes arising.
Oversight/Mistake
Sometimes, programmers just write bad codes, which eventually lead to technical debts. Regardless of whether the bad code exists as a result of the mistake of the coder or not, the fact is that mistakes result in technical debts, and because they are not scalable, they will eventually have to be fixed.
Lack of Awareness of the Effects
Sometimes technical debts arise because the coder fails to realize or acknowledge how harmful technical debts are in the long run. This could stem from a legitimate ignorance of the harmful effects of taking shortcuts during programming, or it could be a willful disregard of the consequences.
Intention
Technical debts can arise intentionally by the deliberate actions of the coder or the organization.
Lack of Modularity
This arises mostly because one code can serve different business logic at the same time. This sort of situation makes handling software a lot harder. With each code a developer writes, the more chances are that they would experience challenges with modularity.
Evaluation of Technical Debt
Technical debts should never be calculated manually because that would be quite arduous. It would mean having to manually enter the code to determine the current problems and the possible future ones. Apart from how time-wasting the manual process is, there is the possibility that the codes would have changed form at the end of the manual process.
One way to carry out the evaluation is through performing a static analysis using some tools that support it. Some of the tools that can be used include Coverity, SonarQube, Check Style, and Closure Compiler.
Generally, there are two ways of calculating technical debts. In the first approach, it could be obtained by calculating the technical debt’s ratio following code ratio. Here, the initial estimate or the overall time needed to develop the app would be used to determine the time required to fix the technical debt.
In the second approach, you could directly make use of the estimates given by the various tools such as SonarQube. This will be combined with the lists of the technical debts as well as their reference codes. From the tools, you could get an accurate estimate of the length of time needed to fix it.
Evaluating the technical debt will give you a sense of how many days it will take to fix the technical debt. The more debts there are, the longer it will take you to fix it.
Resolving Technical Debts
What if technical debts have occurred and you are at a loss about what to do? There are certain steps you can take to manage the technical debts.
Firstly, you should acknowledge that the technical debts exist and communicate the same to your team. In communicating, you should be clear about what has happened and what needs to be done to correct it. You should make sure that you clearly communicate the need to take care of the technical debt at the earliest opportunity.
After informing your team of the technical debts, there are three approaches you could take. In the first approach, you could decide to continue with the system as it is. In this scenario, the application will be used as it is.
Alternatively, you could decide to refactor the application. Refactoring is done with the aim of reducing the complexity in the app as well as cleaning up the app’s structure. With refactoring, the behavior of the software will not be changed; the only affected part will be the internal structure.
Finally, if the two options discussed above do not work, you will have to replace the code entirely. One problem with this is that it could lead to new technical debts, but that could be a better trade-off in the long run.
Avoiding Technical Debts in the Future
Of course, it is a no-brainer that avoiding technical debts is definitely smarter than trying to fix them when they arise. Apart from the fact that it saves you both time and stress, it also makes sure that the residual consequences that come from having technical debts from the beginning are absent.
It could be argued that technical debts, in and of themselves, are not bad. They are problematic generally because they are debts that have to be paid back, and humans are not the most responsible species on earth. Consistently choosing a weaker option will generally weaken the strength of your software, and make it harder to improve on functionalities later on. In all, avoiding technical debts is the best bet for anyone.
So, how do you prevent technical debts from arising:
The idea here is to keep everyone abreast of the process and bring them up to speed with the requirement for whatever task being carried out. Creating a backlog lets everyone see the tasks left undone, and the paths to take in achieving them.
If you are a programmer yourself, you have to learn to prioritize putting out quality work over lots of work. Make sure your codes are clean, and your apps or other software are developed to perfection. Understand that the temptation to take shortcuts will not be worth it because eventually, you’ll still have to carry out the tasks you jettisoned.
If you head a team, you have to communicate these same values to team members. Members should be taught to create result-oriented solutions and shun shortcuts.
Generally, an in-depth knowledge of what technical debt is and how to avoid it can be useful in preventing them from arising in the first place. When you arm your developers with the requisite knowledge, they will better avoid the traps technical debts pose.
Some coding practices make it more likely than not for you to fall into technical debt. Thus, it would be great to avoid tight coupling, employ abstraction and refactoring.
Regular updates of technology can be an excellent means of forestalling technical debts. In updating, you have to make sure that what is being used is the latest framework, databases, and application software.
Conclusion
Technical debts, in a vast majority of cases, are unavoidable as long as you continue to develop programs and write codes. However, the chances of their occurrence can be greatly reduced when the steps listed above are followed. Also, in the eventuality of technical debts, all hope is not lost. Stay calm, be confident, act accordingly.
