An Overview of Technical Debt
An Overview of Technical Debt
Join the DZone community and get the full member experience.Join For Free
Is the concept of adopting a continuous everything model a daunting task for your fast moving business? Read this whitepaper to break down and understand one of the key pillars of this model in Continuous Governance: The Guardrails for Continuous Everything.
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 instalment (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 instalment (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 instalment (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."
Why is it important for a software practitioner to be aware of technical debt and try to avoid incurring it? To understand this, let us first understand the components of technical debt. Technical debt is a result of principal (the original hack or shortcut), and accumulated interest incurred when the principal is not fixed. The interest component is compounding in nature; the more you ignore it or postpone it, the bigger the debt becomes over time. Thus, it is the interest component that makes technical debt a significant problem.
Jim Highsmith  talks about how Cost of Change (CoC) varies withtechnical debt. As illustrated in the above figure, a well-maintained software system shows actual CoC near to the optimal CoC. As technical debt increases, the actual CoC also increases. It becomes difficult to introduce a change if technical debt keeps increasing and there are no efforts to reduce it. In extreme cases, it can lead to "technical bankruptcy".
Borland bought Arago to make dBase for Windows but started the development from the scratch; before they can make to the market, MS Access captured the market. All of the above cases highlight strategic mistakes of these companies that wiped their market share. Thus the "Risk of losing the market" is indeed a significant factor to consider when the question (i.e. "Refactor or re-write") is posed. In this context, Refactoring could be favored since the product is always market-ready and refactoring can consistently improve the quality to sustain the product for a longer period.
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.
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.
[Note: This article was originally published in designsmells.com website by Girish Suryanarayana, Tushar Sharma, and Ganesh Samarthyam].
 "The financial implications of Technical Debt " by Jim Highsmith.
 “Refactoring for Software Design Smells: Managing Technical Debt ”, Girish Suryanarayana, Ganesh Samarthyam, Tushar Sharma, ISBN - 978-0128013977, Morgan Kaufmann/Elsevier, 2014.
Opinions expressed by DZone contributors are their own.