If you’re like me and subscribe to or follow sites and people who care about software, it is likely you are regularly barraged with emails, Tweets, LinkedIn Updates, etc. discussing technical debt and attributing many computer related disasters to be a direct result of technical debt.  The notion of technical debt was introduced in 1992 by Ward Cunningham, writing “Shipping first time code is like going into debt.  A little debt speeds up development so long as it is paid back promptly with a rewrite” [1].  The term technical debt is often used as a metaphor to help ease business leaders understand the cost of making poor decisions during development or making wise decisions during development (such as a short cut to meet a time to market goal) and not following up with a quick rewrite to address the short cut.  The term is also used to describe cost of addressing the structural quality issues associated with an application; a situation that sometimes creates confusion.

Technical debt refers to conditions that exist in a software application that don’t necessarily represent bugs or defects in the software that a user might happen upon, but rather are indications that the there are problems with the structural quality of the application. From the metaphorical perspective, technical debt allows for conversations between the development team when conflicts exist as to whether to properly meet all technical goals or whether to take a shortcut here and there in order to meet some business goals (time to market, bug fixes for key users, etc.).  When these discussions occur the development team can use technical debt as a way of making business leaders understand that what they are asking for comes with a price that needs to be paid.  Technical debt includes but is not limited to:

  • Lack of documentation
  • Lack of adherence to process, standards or established best practices
  • Missing tests, poor test coverage
  • Lack of modularization
  • Architecture or design that is not well thought out or scalable
  • Failure to keep up with technology.
  • And the list goes on….

Clearly these do not necessarily have an impact on the user but if not addressed, they will have an impact on the organizations ability to maintain and update the software, and if they persist long enough the overall quality of the software application will continue to degrade.  These types of things represent the principal of the debt, the impact they have on future touches to the debt ridden code can be thought of as the interest for that debt.

While technical debt, as a metaphor is a useful tool for communication, technical debt is also a real thing.  The term technical debt, when not a metaphor refers to the costs associated with addressing violations (of best practices, standards, test creation, etc.) that currently reside in your code, whether they were introduced consciously or through sloth.  While the fact that there is technical debt implies that bad code may have been written; in the context of the metaphor, having technical debt is not what happens when inexperienced, unsupervised junior developers (or just bad developers) write bad code because they don’t know any better.  That’s just bad code. The resulting technical debt resides in your code either way and if you are determined to address technical debt it too needs to be addressed – regardless of how it got there in the first place.

Technical debt is not the same as defects but much of it needs to be addressed if an application needs to be maintained for the long haul. 

Having said that, organizations that do respect the metaphor… those that actually don’t create violations without first discussing the future impact of those violations are clearly in a much better position to tackle the real technical debt in their applications than those who’s debt is incurred unintentionally.

 

[1] http://en.wikipedia.org/wiki/Technical_debt