Technical debt is very similar to financial debt. When a person takes a loan (or uses his credit card heavily), he incurs debt. If he is paying the installment (or the credit card bill) then the created debt is fine and does not create further problems. However, if the person does not pay his installment (or bill), 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 his installment (or bill) for a long time, then accrued interest makes it even difficult to make him pay. In an extreme case, the person has to declare himself as bankrupt.
What is Technical Debt?
Technical Debt is a metaphor coined by Ward Cunningham in a 1992 report. In his report he says – “Although immature code may work fine and be completely acceptable to the customer, excess quantities will make a program unmasterable, leading to extreme specialization of programmers and finally an inflexible product. Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite. Objects make the cost of this transaction tolerable. The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object- oriented or otherwise.”
What does this mean in layman terms? Let’s take the case of a medium-sized organization that develops software products. In order to be able to compete with other organizations in the market, this organization obviously wants newer products out in the market faster and at reduced costs. But how does this impact the software development process? As one can imagine, software developers are expected to implement features faster without having the opportunity or time to reason about the impact of their decisions on the current design. As a result, over time, such a collection of individual localized design decisions starts to degrade the structural quality of the software and structural quality of a software system is one of the vital contributors of technical debt. During future enhancements to the product, the poor structural quality of the software will adversely affect the development tasks. For instance, the software will be much more difficult to understand and analyze or much more difficult to extend. This, in turn, would lead to increased development/maintenance time and costs which would eventually hurt the organization’s interests.
What Constitutes Technical Debt
There are multiple sources of technical debt. On a broader scale, we can categorize the types of technical debt in following categories:
What is Technical Debt?
Technical Debt is a metaphor coined by Ward Cunningham in a 1992 report. In his report he says – “Although immature code may work fine and be completely acceptable to the customer, excess quantities will make a program unmasterable, leading to extreme specialization of programmers and finally an inflexible product. Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite. Objects make the cost of this transaction tolerable. The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object- oriented or otherwise.”
Classic cause of Technical Debt
What does this mean in layman terms? Let’s take the case of a medium-sized organization that develops software products. In order to be able to compete with other organizations in the market, this organization obviously wants newer products out in the market faster and at reduced costs. But how does this impact the software development process? As one can imagine, software developers are expected to implement features faster without having the opportunity or time to reason about the impact of their decisions on the current design. As a result, over time, such a collection of individual localized design decisions starts to degrade the structural quality of the software and structural quality of a software system is one of the vital contributors of technical debt. During future enhancements to the product, the poor structural quality of the software will adversely affect the development tasks. For instance, the software will be much more difficult to understand and analyze or much more difficult to extend. This, in turn, would lead to increased development/maintenance time and costs which would eventually hurt the organization’s interests.
What Constitutes Technical Debt
There are multiple sources of technical debt. On a broader scale, we can categorize the types of technical debt in following categories:
- Code debt: Examples- code duplication, static tool rules violations, and code smells.
- Design and architecture debt: Example - Design smells, design rules violations, and architectural rules violations.
- Test debt: Examples – Lack of tests, inadequate test coverage, and improper test design.
- Documentation debt: Examples – No documentation for important concerns, poor documentation, outdated documentation.
- Defect debt: Examples – Unfixed list of known defects.
How Technical Debt Occurs?
The software engineering community has identified several common causes that lead to technical debt. These include -
- Schedule pressure
- Lack of good/skilled designers
- Lack of awareness of technical debt
- Lack of applying design principles
- Lack of awareness of design smells and refactoring
Often, given the different cost and schedule constraints of a project, it may be okay to incur technical debt temporarily. But what is important is that this debt should be paid off as early as possible.
