Click here to Skip to main content
Click here to Skip to main content

Tagged as

What is Technical Debt?

, 12 Aug 2014 CPOL
Rate this:
Please Sign up or sign in to vote.
What is technical debt?

Introduction to Technical Debt

I first came across the concept of Technical Debt whilst reading a recent copy of the Microsoft Developers Journal called the MSDN Magazine. It struck a chord, as it's a concept that all software developers are familiar with, even if not by name.

In every software system, there are areas of the code that are difficult to change, that strike fear into us when we are required to change them. Those areas of the code that make you think "Oh please no". They are difficult to modify or extend, and thus working in those areas are prone to making the system less stable. They will also generally require a greater degree of regression testing to ensure that you have not inadvertently modified other areas of the system.

Technical Debt may be introduced into the code base by conscious decision (in order to make this deadline, we will deliberately and consciously write something "quick and dirty"). Or Technical Debt may be introduced unconsciously by factors including:

  • low skilled developers
  • ever changing requirements
  • impossible deadlines
  • poor project planning
  • all of the above

In short, you have acquired Technical Debt. You have taken a shortcut with the code to meet a deadline, and at some point, you are expected to repay the debt, i.e., to refactor the code and remove all the hard coded values, shortcuts, etc. that were introduced to meet the deadline.

It is not necessarily always a bad thing to acquire Technical Debt. If the decision is made consciously to meet a deadline where there is a financial gain to be made, such as if there are penalties for late delivery on a project, or a bonus for meeting the deadline. In such cases, then clearly meeting the deadline takes precedence. What needs to happen next (and unfortunately rarely does) is that the business then allows the development team to repay the debt.

The reality is that the business has already moved onto the next project, and the development team is never allowed the opportunity to repay the Technical Debt. Over time, with successive projects each adding more and more Technical Debt, the code base slowly erodes in quality, and the development team struggles to meet each new deadline. The code base becomes increasingly harder to modify and changes become ever more difficult to make.

Similarities with Financial Debt

The phrase was initially coined by Ward Cunningham, and uses the metaphor of finance. There are certain kinds of debt that are cheap to repay, where the interest rates are low and repayments incur little cost. Then there are those kinds of debt that are difficult to repay as the repayments are high. A credit card would be a good example of the latter, where their high interest rates make them an option that should only be considered as a last resort.

An example of a low interest debt would be hard coding a single value into the code base. This can be easily and quickly refactored at a later date. An example of a high interest debt would be compromising on the underlying design. This would be difficult to repay due to the associated costs (time) involved.

The major downside of Technical Debt is that it has an associated cost. Being difficult to modify will lead to longer development lead times. It will require additional testing, particularly regression testing. All of this extra time and effort involves greater cost.

It also ensures that the software system in which the Technical Debt finds itself will be less likely to be able to respond to customer changes, or fluctuations in demand or functionality. If there is a swing in customer demand or a new market opportunity opens, and the system needs to change to be able to respond to this, it will require far greater resources to make those changes in a software system which has a higher degree of Technical Debt.

I remember whilst working for one particular company, a colleague telling me how he disliked modifying certain areas of the code, as it was like "playing Kerplunk with the code" (think Jenga if you haven't heard of Kerplunk). What he was referring to was that by making changes to the code, the whole lot would collapse.

Repaying Technical Debt

Technical Debt is a simple concept that every software developer both understands and can sympathize with. If left unchecked, it can lead to significant cost implications, so it is worthwhile investigating and taking the time to remove it. There is a strong financial incentive to make the case for removing Technical Debt, and this should be proposed as a project as early as is convenient.

In one company I worked for, we consciously repaid Technical Debt by spending one day each fortnight refactoring areas of the code where we had previously introduced shortcuts to meet a deadline. It is generally accepted that a developer ought to spend around twenty percent of their time repaying Technical Debt. So by rights, one day per week should be the appropriate balance. In reality, this is rarely achieved.

If the business understands nothing else, it understands the concept of cost, particularly where it is detrimental to the business. Therefore, a smart business will invest time in repaying Technical Debt.

After each and every project, the accumulated Technical Debt ought to be repaid so it never gets too high. This needs to be understood by the business, at all levels. Not just by the Development Team. Before the business commits to the next project, they need to repay the Technical Debt they have acquired in the last project.

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Share

About the Author

Dominic Burford
Software Developer (Senior) Marval Group UK
United Kingdom United Kingdom
I am a professional software engineer and architect with over fifteen years extensive commercial development experience, focusing on the design, development and testing of software solutions using Microsoft technologies.
 
I have experience of building a wide variety of applications from desktop to client-server to web to mobile and tablet using Visual Studio.
 
I have experience of architecting scalable, distributed, high volume web applications that are accessible from multiple devices due to their responsive web design.
 
I have developed enterprise mobile applications for the Android platform delivering real-time data securely to tablet devices via WCF services.
 
I am proficient in .NET, ASP.NET (VB.NET / C#), Windows and Web Services, WCF, SQL Server, LINQ and other Microsoft technologies. I am also familiar with HTML, Javascript/JQuery, XML, XSLT and many other web related technologies.
 
Outside of work I have two beautiful daughters. I enjoy cycling, running and taking the dog for long walks.
 
Visit my website here http://www.dominicburford.co.uk
Visit my Github repositories here https://github.com/DomBurf
Follow on   Twitter   Google+   LinkedIn

Comments and Discussions

 
GeneralImposed debt Pinmembercspitzer13-Aug-14 14:48 
GeneralRe: Imposed debt PinmemberDominic Burford13-Aug-14 21:43 
QuestionA big ball of mud Pinmemberkathleenfibbergibbet13-Aug-14 8:44 
AnswerRe: A big ball of mud PinmemberDominic Burford13-Aug-14 21:36 
QuestionIf Only More People Got This! PinmemberPeejayAdams13-Aug-14 3:43 
AnswerRe: If Only More People Got This! PinmemberDominic Burford13-Aug-14 6:28 
QuestionTrashing PinmemberTomaž Štih13-Aug-14 2:04 
AnswerRe: Trashing PinmemberDominic Burford13-Aug-14 3:05 
GeneralMy vote of 5 PinmemberJoe Gakenheimer12-Aug-14 7:26 
Generalwell-written PinprofessionalBrian A Stephens12-Aug-14 5:22 
GeneralRe: well-written PinmemberDominic Burford12-Aug-14 5:54 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

| Advertise | Privacy | Terms of Use | Mobile
Web03 | 2.8.1411022.1 | Last Updated 12 Aug 2014
Article Copyright 2014 by Dominic Burford
Everything else Copyright © CodeProject, 1999-2014
Layout: fixed | fluid