An Overview of Technical Debt

Ganesh Samarthyam, Tushar Sharma, Girish Suryanarayana

AN OVERVIEW OF TECHNICAL DEBT WWW.DESIGNSMELLS.COM

What is Technical Debt? 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."

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 [1] 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

AN OVERVIEW OF TECHNICAL DEBT WWW.DESIGNSMELLS.COM

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

AN OVERVIEW OF TECHNICAL DEBT WWW.DESIGNSMELLS.COM

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.

References:  [1] "The financial implications of Technical Debt" by Jim Highsmith.

About  the  Authors:        Ganesh   Samarthyam   (sgganesh@gmail.com)   is   an   Independent   Consultant   and  Corporate  Trainer  based  in  Bangalore.    

AN OVERVIEW OF TECHNICAL DEBT WWW.DESIGNSMELLS.COM

Tushar   Sharma   (000.tushar@gmail.com)   is   a   Technical   Expert   at   Research   and  Technology  Centre,  Siemens  Technologies  and  Services  Pvt.  Ltd.,  Bangalore.  

Girish  Suryanarayana  (girish.suryanarayana@gmail.com)  is  a  Senior  Research  Scientist  at   Research   and   Technology   Centre,   Siemens   Technologies   and   Services   Pvt.   Ltd.,  Bangalore.    

AN OVERVIEW OF TECHNICAL DEBT WWW.DESIGNSMELLS.COM