Technical Debt in software development refers to technical problems(deliberate or unintentional), in a software, left uncorrected, mostly with the objective to speed up the phase of development . It is also referred to as Tech Debt.

The term Technical debt was coined by Ward Cunningham, who is one of the authors of Agile Manifesto in the early 1990s. Cunningham compared the problems in code arising out of developing software fast, with incurring financial debts. Incurring Technical Debt in a software is ok as long as it is paid back in time or in this context correct by rewriting the code. However if it is not paid back in time, this debt as in the case of financial debt starts to grow and at a point will become unmanageable.

Categories of Technical Debt

Ward Cunningham used the term Technical Debt in software development in a limited context and had not intended issues related to inexperienced developers, inefficient process etc. However the concept evolved and the term of Technical Debt or Tech Debts were also used to include other types of issues. Let’s see various categories of Technical Debt in software development as we know today

Reckless Technical Debt

Reckless Technical Debt are often bad code or designs introduced to the software due to ignorance or shortcuts adopted. Following are some examples of Reckless Technical Debt:

• Bad code developed due to lack of experience 
• Defect or bugs in the software which, though discovered, is not fixed
• Lack of automated testing where it was required 
• Lack of enough test coverage

These types of Technical Debt can be avoided by providing enough training to the team and following good coding practices, testing etc.

Unavoidable Technical Debt 

Unavoidable Technical Debt are not preventable. These types of issues are caused due to reasons that are beyond the control of the development team or the management . Following are examples of unavoidable Technical Debt 

• Code or design that become less efficient due to change in requirements.
• Code or design that become less efficient due to technology getting obsolete 
• Issues caused due to third party components getting outdated and fail to catch-up with change environment
• Issues arising out of changes in the platform on which the softwares runs.

Prudent Technical Debt

Prudent Technical Debt or sometimes referred to as Strategic Technical Debt are purposefully introduced, to save cost or reduce delivery time. Following are some examples of prudent Technical Debt.

• Shortcuts adopted to speed up delivery in case of time sensitive projects 
• Releasing product early to customers with some known defects for faster customer feedback 
• For releasing the product to market soon, in order to generate revenue and do further development based on the revenue generated.
• To include maximum possible features with the available budget, in order to showcase it to investors.

In all these cases the Technical Debt in the software are introduced deliberately as a leverage, for short term gains. The intention here is to fix these issues in a more convenient time in future. It is like borrowing from the future.

Impact of Technical Debt

Characteristics of Technical Debt in software matches very well with financial debt. As in case of financial debt, assessing whether the debt is good or bad depends on how it is managed. Debts can boost  the business growth if it is prudently used and paid off early. If it is not paid off in time interest accumulates and after a point, it can bring down the business. Same is the case with Technical Debt in software development. It has to be paid off before it gets to a point of no return . Following are some adverse impact of having high technical debt in a software product 

Increased delivery time

Technical Debt is often incurred in order to speed up delivery, in the short term. However in the long term it increases overall delivery time. Just like interest paid in financial debt, in technical debt there is an overhead associated with Technical Debt which adds to the effort of future development. The team has to make a choice of either pay off the entire technical debt in full or incur the recurring overhead. In either case the delivery time is going to be impacted when compared to a situation without the technical debt.

Increased number of defects

Technical Debt in a software comes in the form of quick fixes, or defects that add more complexity to the software code, even if it may not be apparent to the user. Working around these Technical Debt will add more complexities and will result in introduction of more defects. 

Poor performance of the team

Teams working on softwares with high technical debt are often underrated on performance even if they may not be directly responsible for this. A substantial portion of the team’s effort is often spent on solving the issues created by the technical debt, leaving them with relatively less time for the actual feature development and creative work . 

Unknown breaking point

Working on source code marred with technical debt results in creation of more Technical Debt , unless there is a deliberate attempt to clean the Tech Debts. If this continues, it will reach a breaking point . At this stage the software becomes so unstable and the maintenance of the software becomes so hard, that the financial viability of the software comes into question. It is difficult to predict when this braking point will reach. It is like snow piling up on the mountains and at some point an avalanche will be triggered.

Decreased predictability

Huge Technical Debt in a software will decrease predictability in the software development process. It will increasingly get difficult to say how long it will take to complete a new feature. This is because the development will have to not only work on the feature, but also sort out all the complexities the technical debt in the code will be bringing.

Low team morale

Working on code with high levels of Technical Debt is very frustrating. A substantial portion of developers effort will go into working around the technical debt, resulting in relatively less output visible to end-users. This result in low moral of the team members

High maintenance cost

Maintenance cost for softwares with high technical debt is usually high. Usually correlation between Technical Debt and maintenance cost is non linear. As the technical debt increases in a software, it’s maintenance cost starts rising exponentially. After a threshold, the rise in maintenance cost will not be viable financially. At this stage, a decision may be made to scrape the software and develop a new software from scratch resulting in high investment.

Low customer satisfaction

We learned how high Technical Debt results in a high number of defects in the software. Repeated occurrence of defects in a software will not go well with customers who are using it. We also saw how increased Technical Debt makes it hard to predict the effort required to complete a feature. This also holds good with effort required in fixing issues that customers report. This again affects the customer satisfaction level negatively.

What causes Technical Debt in softwares?

Different types of Technical Debt are incurred in different ways . Prudent or strategic Technical Debt are taken purposefully for short-term with a plan to correct it going ahead . In case of unavoidable Technical Debt also we saw there are external factors and the team has relatively less control on it. In case of reckless Technical Debt, it is totally avoidable. Let us see in detail how these Technical Debt are incurred

Unrealistic deadline

This is the most common cause of Technical Debt. While developing a software, the required amount of effort  should be spent on developing each feature . Some time the timeline is set such that there is not enough time required to complete the feature. This may be due to different reasons like commitments given based on underestimated effort, pressure from clients to deliver sooner, lack of experienced resources etc. The ideal choice here would be to either reduce the scope or extend the deadline, however many times both these options are not acceptable to the decision makers and the team is expected to increase their efficiency. What happens in this case is that shortcuts are adopted to deliver fast and quality is compromised and stays in code as the technical debt. 

Increasing Development speed

Often there is pressure on the team to show efficiency by increasing their output. This may be in the form of  features completed within a given time . An increase in efficiency may be artificially shown in these cases by lowering the quality and incurring Technical Debt.

Poor definition of done

Definition of done is the criteria used to assess whether a particular feature is completed or not. If the definition of done is very lenient that will cause creation of low quality deliverables and Technical Debt. A strong definition of done will ensure that Technical Debt is not incurred recklessly.

Debt atracts debt

Existence of Technical Debt in a software will cause more Technical Debt to be incurred. Whenever the team decides to postpone cleanup of Technical Debt they will be building up one the existing technical debt. This will result in more technical debt and the effort required for cleanup later will be more than the effort it would have taken to clean up now.

Managing Technical Debt

Technical Debt is inevitable in software and it is rare to find a software without Technical Debt. Even if it is popsie to create software without technical debt, it maynot be financially prudent. It all depends on how we ensure that it is controlled. Earlier in this article we discussed how a breaking point comes as Technical Debt keeps on growing. So it is very important to manage the Technical Debt effectively so that Technical Debt remains under control. Let’s see how this can be done 

Controlling the occurrence  of Technical Debt 

First thing we need to see as part of managing technical debt is to decide whether to incurre a technical debt . Reckless Technical Debt are always discouraged. And we may not be able to do anything about uncontrollable Technical Debt. However in case of prudent Technical Debt we always have a choice . All decisions on incurring a technical debt should be backed by technical and financial reasoning. We need to consider how much effort we are saving now by not doing something, how much effort we would have to spend to do the same thing later, what will be the extra effort in future developments, if the Technical Debt remains in the system. One more thing to consider here is that, the longer the technical debt remains in the system, greater the effort required to fix it

Servicing technical debt

Next important thing that has to be done is preventing the technical debt to grow in the software by servicing it or in other words correcting the bad code by rewriting it. For this to happen it is essential to quantify and track the Technical Debt along with an effort estimate,in the same way planned features of the software are tracked. It can be either maintained in the same product backlog along with other features or a separate technical debt backlog can be created. It is a good practice to have a threshold set for Technical Debt beyond which total Technical Debt should not increase. This helps to check the level of Technical Debt by infusing an urge to reduce Technical Debt as it nears the threshold.

When it comes to servicing Technical Debt it is not required that all the Technical Debt should be serviced at once.  Technical Debt also has to be prioritised based on its severity and effort required to fix it. High priority Technical Debt should be fixed first.

When can Technical Debt be ignored

It is not always required to service Technical Debt.This is an exception when we compare technical debt to financial debt. All  financial debt need to be service but following are some cases where it is ok to do nothing about Technical Debt in the software :

• Short duration project – when we know the the software is build only to be used for a short span of time and will be discarded after that 
• Prototypes – In case of proof of concepts and prototypes which are built only for demonstration purposes.
• The software is about to be decommissioned- products that have reached the end of its life and is about to be decommissioned.

Closing Note

Technical Debt, as in case of financial debt , cannot be termed good or bad. It all depends on what purpose it was acquired and how soon it is paid back. Technical Debt is time borrowed from the future and has to be paid back. If used prudently it brings advantages , if not it creates problems.