Technical Debt

Technical debt accrues when a design or construction approach is chosen that is expedient in the short term, but increases complexity and is more costly in the long term. That is, some aspects of quality are deferred for the sake of faster delivery.

The metaphor of technical debt is compared to monetary debt. If it is not repaid, it accumulates ‘interest’, making it harder to implement changes later on. Another way to view it is that when technical debt is not addressed it results in increased software rot in the case of software.

The term originated in software development, but may be applied to other fields. This entry describes the term as applied to software.

Technical debt includes, for example, postponement of:

  • Refactoring code to reflect improved understanding of the software design and architecture
  • Refactoring code that is confusing and difficult to modify
  • Writing automated tests
  • Fixing bugs

When technical debt accumulates there are various harmful effects to the business, such as:

  • It becomes increasingly difficult to implement new functionality
  • Stakeholders are upset when new features take longer and longer to deliver.
  • Developer morale decreases

Note that technical debt is not inherently good or bad. It depends on how it is used, what the tradeoffs are, and what the intent is. The following five-minute video with Ward Cunningham who originated the term is clarifying.

Background of the Term

The metaphor was described by Ward Cunningham in the article The WyCash Portfolio Management System

Further Learning

Technical Debt – ProductPlan – blog post
Technical debt – Wikipedia – wiki post

This entry was posted in t. Bookmark the permalink.

Leave a Reply

Your email address will not be published.