Technical debt

Technical debt in software development does not mean poorly written code or outdated libraries.

When we develop software, we often have an inaccurate or partial understanding of the problem. Our code reflects this understanding, and, as a result, it is likely also inaccurate.

Given this lack of understanding, we may choose to release the software anyway. In doing so, we accrue technical debt in the form of code that is based on an incomplete understanding of the problem. However, this approach allows us to gain valuable feedback through experience.

As our understanding grows, so does our awareness of the debt. Over time, we can more accurately identify how to model the problem in our code (e.g., which abstractions to use). We experience the effects of this debt every time a model fails to align with our improved understanding of the problem space. Unless we address this debt, the “interest” will increasingly impact our maintenance costs as well as the cost of developing anything new.

Technical debt represents the misalignment between our understanding of the problem and the code. It can also be a strategic decision to incur technical debt in order to gain a better understanding of what we are doing, provided there is a clear intention to address it later.

The debt metaphor in software development was coined by Ward Cunningham.