December 15, 2016
What we are going to learn is as follows:-
1) What is Technical Debt?
2) What Constitutes Technical Debt?
“Technical debt is the debt that accrues when you knowingly or unknowingly make wrong or non-optimal design decisions.” Technical debt is a metaphor coined by Ward Cunningham in 1992. Technical debt is analogous to financial debt.
For example: When a person takes a loan, he incurs debt. If he regularly pays the installments then the created debt is repaid and does not create further problems. However, if the person doesn’t pay his installment, a penalty in the form of interest is applicable and it mounts every time he misses the payment. In case the person is not able to pay the installments for a long time, the accrued interest can make the total debt so ominously large that person may have to declare bankruptcy.
Similarly, When a developer opts for a quick fix rather than a proper well-designed solution (i.e he is violating design principles) he introduces technical debt. It is okay if the developer pays back the debt on time. That is, it is okay if developer even after violating principles is able to refactor it on time.
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. 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.
I hope you understand why technical debt plays important role in software industry. So please learn design principles, examples of design principles, ability to find bad design smell, refactor them using code tools, code review, self-review on time and avoid technical bankruptcy.
Well, know dimensions of technical debt include:-
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.
Let’s discuss design debt for a medium-sized organization that develops software products. To be able to compete with other organization in the market, this organization obviously wants to get newer products on the market faster and at reduced costs. But how does this impact its software development process? As one can imagine, it’s software developers are expected to implement features fasters. In such a case, the developers may not have the opportunity or time to properly assess the impact of their design decisions. As a result, over time, such a collection of individual localized design decisions starts to degrade the structural quality of the software product, thereby contributing to the accumulation of design debt.
Interesting Question in the context of what constitutes technical debt is whether defects/bugs are a part of this debt. Some say yes and some say no. Some say yes because if managers decide to release a software version despite it having many known yet-to-be-fixed defects, these defects are part of the technical debt that has been incurred.
Some say no because according to the difference between defects and technical debt is that defects are visible to the users while technical debt is largely invisible. Defects are rarely ignored by an organization and receive much attention from the development teams. On the other hand, issues leading to technical debt are mostly invisible and tend to receive little or no attention from the development teams. Why does this happen?
This happens because defects directly impact external quality attributes of the software that is directly visible to the end users. Technical debt, on the other hand, impacts the internal quality of the software system and is not directly perceivable by the end users of the software.