‘Technical Debt’ is an interesting expression, or perhaps some sort of myth? Those were my exact thoughts when I first heard about it. ‘Financial debt’ is the only kind of debt that made sense to me, and surprisingly technical debt is quite similar – put inside a software development niche. There are multiple types of technical debts, so naturally there is no single definition. The term was first coined in the early 90s by one of the Agile programmers – Ward Cunningham. A generic explanation of technical debt is the extra/additional development work that arises when code delivered previously is functional, but not in its complete/best form. This suggests quick shipment (deployment of first-time code) that allows modifications to be made later on.

I will quote a ‘teenage practice’ that most of you can relate to, just for better elaboration of the topic. Suppose you’ve planned to attend a majestic concert with your friends, but your mom puts forward a preposterous condition at the eleventh hour: clean your room or you’re not going anywhere! You have to meet your pals in ten minutes, so what do you do? Obviously, you stash everything under the bed like you always do. Under your bed isn’t a pit-less black hole, so eventually you’ll outstrip the capacity. Sooner or later you have to take care of the mess that you put away by opting for a temporary solution. If you continue to add more and forget about the previous loads, don’t act surprised when disaster strikes!

I remember this Sitcom called ‘Even Stevens’ that I watched regularly on Disney Channel as a child. The lead character was a chaotic teenage boy who had severe issues on the subject of cleanliness, particularly with his room. He often disposed off left over food under furniture and over time that gave birth to some strange moulds/microorganism colonies. The family had to call in ‘special forces’ to get the room disinfected and terminate the disgusting species growing within. The point is if you keep accumulating things and never actually deal with them, the consequences will be dire.

Technical Debt and its Types

Technical debt is not necessarily a bad thing, as long as it is regularly tracked and managed. It can emerge as a result of various circumstances, mainly inflexible deadlines for project completion. Generally speaking, technical debt can be divided into three categories:

#1. Planned Technical Debt

This is the most common type of technical debt, where software development companies are well aware of the risks and costs associated with the tasks they rack up. IT firms have to keep up with contracts or promises they made with the client. Sometimes deadlines are too tight and the development team has no choice but to act hastily. Providing a working product on the set date is the top priority. Hence, this usually involves messy/rushed code that is supposed to be fixed or revised after production.

Planned technical debt usually implies that both the manufacturer and customer knows about the compromises made. A schedule will be organized to gradually address the shortcomings before they cause bigger problems in the future. All parts of the code that need to be amended are recorded precisely, so that it is easy to return and apply the required changes. If testing was not carried out earlier or some features are missing, they can be implemented afterwards; improvements are dispatched step-by-step.

The piled up work usually does not pose any immediate threats and the product is able to perform in an acceptable manner. However, if the hidden issues are left the way they are, they can lead to unpleasant outcomes, as serious as entire system failure. Repairment at that point can cost immeasurable amounts of time and money. If the development firm utilizes best development practices and generates high quality code from the beginning, they can sidestep this kind of technical debt. For the majority of cases, this is a hopeless matter due to unavailability of ample time.

#2. Unintentional Technical Debt

This type of technical debt arises when the software development agency or team is not voluntarily compromising on work and is oblivious to potential pickles in the code. The team believes it is delivering to the best of its capabilities and goals are being met. The reality is a faulty software design or a codebase full of errors. This situation typically occurs when the developers are inexperienced, lack skill or simply follow poor development practices. Other reasons include vague/inadequate communication with customer or between DevOps. Outdated technology can also be deemed as a path that leads to unintentional technical debt, though management is the true culprit here.

#3. Unavoidable Technical Debt

This is the type of technical debt which is not initially expected, but is enforced in accordance with change of demands at secondary/tertiary stages of development. This happens when new technology is introduced in the market, the nature of business is modified or entirely different features are requested. Sometimes all the work done by the development team beforehand goes to waste and they might have to start from scratch. There is no way to avoid this technical debt because it could not be eliminated with cleaner code or better designing/engineering from the starting point.

Justifications of Technical Debt

As I mentioned before, technical debt is often indispensable and there’s seldom a viable option is to work around it. Taking the shortcut or pursuing the act of surrender towards it is still wrong, though morally admissible. There are times when technical debt can be averted; other times it is understandably impossible. Normally, delivery is more important than clean code and smooth functionality, because payments/transactions depend on it. The main thing is that the developing team did their best, considering the unreasonable time frame. On the contrary, if the team members did not imply a productive approach and wasted time on useless aspects – the resulting technical debt is on them (unjustified).

Even if the technical debt incurred is justified, the game doesn’t end there. You are bound to repay that debt and only then you can save yourself/your organization. Before you make the huge decision, be sure that the interest you will pay on your debt is practicable and lucrative. Typically, development teams plan to refactor a project after hurried deliveries but fail to comply because there are other assignments to take on. The same cycle of flurry is repeated with every new project and the event of re-visitation becomes a forgotten shenanigan. In the long run, deep rooted glitches will slow down the system and ravage all progress. When code has become ancient, it is difficult to identify bugs and rescue your application.

Final Thoughts

Unlike financial debt, technical debt is difficult to measure. The only applicable metrics are time-to-market vs. extra work for compensation. The sole way to escape the trap is by frequently taking out time to make restitution. There will always be more work and free time will never appear miraculously. Every time you prepare for a new release, don’t restrict it to new features; remember to squeeze in part of your pending debt.