top of page

Learning Center

  • Writer's pictureElegant Software Solutions

Defining Technical Debt

Updated: May 29, 2020

Technical debt is a metaphor for a phenomenon in software development where imperfect code creates extra work for future maintenance of a project. It was coined by Ward Cunningham because the ‘interest’ paid in the form of extra work resembles interest payments in financial debt. The metaphor has been expanded upon by others, and a classification system exists that differentiates types of technical debt based on certain factors. While technical debt is intrinsically negative, there are scenarios where it can be leveraged to attain more important goals.

The popularity of the term ‘technical debt’ largely stems from the surprising similarities between financial debt and the software development phenomenon that it describes. Like financial debt, technical debt incurs interest payments on top of the principal (the original money owed in financial terminology). Whenever a developer remedies a bug or makes an improvement to the project in which technical debt has accrued, the interest payment appears in the form of excess work that must be done to compensate for imperfect code or poor design. The circumstances under which technical debt develops can typically be classified by two main criteria.

Much like financial debt, technical debt can be prudently or recklessly incurred. Reckless debt is created out of sheer ignorance, while prudent debt is created despite adherence to best practices and/or design patterns. Another dimension by which to classify technical debt is the willfulness with which it is incurred. Technical debt that is created willfully can be analogized to student loans, where the debtor purposefully takes on debt in an effort to further some other (usually more important) goal. When combined, these two dimensions, willfulness and prudence, compose the four quadrants of technical debt classification invented by Martin Fowler. As illustrated by the diagram, prudently incurred technical debt can be spawned either deliberately or inadvertently.

Technical debt, although intrinsically negative, can be used to further other, more important goals. For this reason, technical debt can be a tool in the hands of skillful software development teams. In instances where rapid development of a product trumps all else, the accumulation of technical debt may be a small burden on the path to being first to market. This is classified as deliberate, prudent technical debt, and is applicable to the student loan analogy used previously. It may seem contradictory that technical debt may be incurred both judiciously and unintentionally, but reality dictates that some technical debt is inevitable. Business plans change, experience with the technology grows, and lessons are learned along the path to project completion. These changes in experience shift the vantage point from which the developers look at the project. What once made sense no longer does, or can be redesigned in a much more efficient way. However, inevitability is not an excuse for inaction; technical debt must be repaid.

Repayment comes in two forms: paying down the principal or paying interest. Every modification to the code base is an interest payment in the form of time wasted compensating for existing design flaws. The addition of any new code that references or relies upon these design flaws will also serve to increase the principal. Therefore, continued neglect of technical debt will eventually lead to crippling interest payments where the effort required to maintain the project is so onerous that it precludes development of new systems. In this way, even software designed by skilled developers can enter into a death spiral of time-consuming maintenance costs.

Technical debt is an important concept in software development because it analogizes an esoteric software phenomenon to a familiar financial one. To truly prevent against its maladies, it’s important to understand its different forms. Accruement of technical debt is not necessarily due to ignorance, but it should always be addressed as soon as it is recognized. This is particularly key in the world of modern software development ideas; it is impossible for a team to be agile when it is laden with burdensome technical debt that prevents new feature development.

Happy Coding!

Elegant Software Solutions

58 views0 comments

Recent Posts

See All
bottom of page