Is Technical Debt Really A Technical Problem? — Paul Henman — Toronto Agile Coach

I often hear the term “tech debt” kicked around but I don’t think it’s well understood.

What is tech debt?

Ward Cunningham created the metaphor to help explain the process of delivering early which leads to the need to go back and “finish” the product. In general, tech debt comes from releasing a product before it is completely done — it’s the gap between what’s done and what needs to be done. That gap should be visible and understood by the dev team and the Product Owner. In fact, the team & PO should agree that there is tech debt before deciding to release; some gaps will be acceptable and some won’t.

What tech debt isn’t
Tech debt isn’t an excuse to write bad code. It may be incomplete because there are parts of the puzzle that are lower priority, e.g. it’s more important to get feedback on the high priority parts first. It may be that parts of the Definition of Done aren’t finished because you’re going to sit with some early-release users to observe them using it so documentation can wait, for example. But poorly written code is just that: bad code, not tech debt.

Accruing interest
One of the reasons that debt is a good metaphor is the concept of interest — the longer you have debt, the more interest you accrue and the longer it takes to pay off. With software development, the longer you leave a product “in debt” the harder it is to build on top of it.