Generally, Business puts lots of pressure on the team to get the product in the market as early as possible. Respective this business pressure has lot of impact on the product. Obviously each product owner want to get their product in the market faster. And yes this can be done. But are you aware that even if this is done it come with the cost. It not taken seriously this fast tracking objective it can lead to total bankruptcy. So it is very important for you as a software professional to understand terms technical debt before it gets too late.

In economics, debt generally refers to something owed by one party, the borrower or debtor, to a second party, the lender or creditor. Debt is generally subject to contractual terms regarding the amount and timing of repayments of principal and interest. Same is true in technical world particularly in Agile methodology and software development organization. And it is equally true in technical worlds also that Debt will increase through time if it is not repaid faster than it grows through interest. If not paid on time it can lead to bankruptcy in technical world we reach to a situation where it is not at all possible pay / correct our debt.

I have seen the normal complains from the Investor that they have already invested a lot of money in the product and they wanted to get the product in the market. But it is very important to understand that every development team should be aware about the technical debt due and it should be clearly communicate to product owner and other important stakeholders at right time before it get too late. So in this article I would like to explore with you what is technical debt and its implication on quality of product and team.

What is Technical Debt?

When team is under pressure to deliver the product earlier because of business pressure either from product owner they cut the corners. Obviously under this kind of situation product owner and scrum master agree to de-prioritize certain task, activities that can be done later. This will help team to bring one increment early in the market by focusing their capacity only on bare necessary task prioritize by product owner and scrum master. However, the task and activities which gets low priorities can not be ignore for long time because if it is not done on time it will affect overall quality of the product. This pending activities and task is called technical debts which if not done can impact badly to the overall product on long run.

Simply putting, “Technical debt is the debt that accrues when you knowingly or unknowingly make wrong or non-optimal design decisions.”

Technical debt (also known as design debt or code debt) is “a concept in programming that reflects the extra development work that arises when code that is easy to implement in the short run is used instead of applying the best overall solution”.

Technical debt can be compared to monetary debt. If technical debt is not repaid, it can accumulate ‘interest’, making it harder to implement changes later on. Unaddressed technical debt increases software entropy. Technical debt is not necessarily a bad thing, and sometimes (e.g., as a proof-of-concept) technical debt is required to move projects forward. On the other hand, some experts claim that the “technical debt” metaphor tends to minimize the impact, which results in insufficient prioritization of the necessary work to correct it.

Real Life Example

Let’s try to understand it by taking real life example from software product development.

Say we need to do code review by the architect once the coding of particular feature is completed before we say this feature is done. Now say for any reason architect is not available on time and code review didn’t happened. However because the features is ready to test QA people start executing test cases on it and all the tests passed successfully as well. During the sprint demo product owner see this feature and thinks its working fine and we should push it to production. And hence we push that particular feature to the Product Release of the sprint. However, because the code review is not done it risk and debt to the product. So, code review of that feature becomes debts for the product and it has to be communicated properly. It can have many impact when we do code review. Here you can understand that Technical debt, impacts internal quality of the software system, and is not directly perceivable by the end users of the software.

For example, it whenever architect will become available and do the code review there are chances that he find that engineer does not follow the design principal and because of it we need to re-engineer this code again. If not done it security of the product will not be achieved as per expected guideline. And let’s say this task task may took another 40 hours. So this 40 hours is our technical debt which will not be perceived by end user but still we have to do it maintain the integrity of the product.

This may be acceptable if code review taken care immediately in next sprint and refactoring done on time.

And if this debt is not corrected on time and carried forward as unaddressed it’s correction comes with more cost. Say fixing a code review related activities requires 40 hours in next sprint.

However, if the developer chooses not to pay or forgets about the debt created (i.e developer is not refactoring the code which has a bad design) the accrued interest on the technical debt piles up, just like financial debt, increasing the overall technical debt. The debt keeps increasing over time with each change to the software; if the debt is not paid at all, then eventually the pile-up becomes so huge that it becomes immensely difficult to change the software.

But if it not addressed in next sprint and again carried forward to couple of another sprint. By that time 4 more feature has been delivered and which is depend on the feature where code review is pending. So now if it has to be corrected to may take 100 hours. So this 100 hours – 40 hours = 60 hours we are working more. Which only because we have not corrected our work in next sprint. This 60 hours may continue increase with each new development happen. So this can be compared with interest in monetary terms.

Continuing our analogy with finance domain 40 hours was our principal (technical Debt) and after 3 sprint 60 hours is our interest.

If the debt is not paid at all, then eventually the pile-up becomes so huge that it becomes immensely difficult to change the software. In extreme cases, the accumulated technical debt is so huge that it cannot be paid off anymore and the product has to be abandoned. Such a situation is called technical bankruptcy.

Types of Technical debts

Below are some of the most import kind of technical debts. These are the main source of the technical debts.

Code debt: Static analysis tool violations and inconsistent coding style
Design debt: Design smells and violations of design rules
Test debt: Lack of tests, inadequate test coverage, and improper test design
Documentation debt: – No documentation for important concerns, poor documentation, and outdated documentation.More details

Please note that technical debt, on the other hand, impacts internal quality of the software system, and is not directly perceivable by the end users of the software.

I hope you understand why technical debt plays important role in software industry how it is important for you to clearly communicate this to stakeholders.

Avoid technical bankruptcy

How you can help in controlling technical debts :

  • Learn design principles,
  • Understand the good Examples of design principles,
  • Develop an ability to find bad design smells,
  • Refactor them using code tools,
  • Please make sure proper code review is being done,
  • Don’t forget to do self-review on time .


Here is the nice artical about Technical debt.

Martin Fowler’s article here he describe Technical debt quadrant here

Please follow and like us:
Understanding and dealing with Technical debt in Agile

Leave a Reply

Your email address will not be published. Required fields are marked *