The True Meaning of Technical Debt 💸 - Refactoring

I've used the term technical debt and people I work with use it as well. I’m not a huge fan of it because I don't think it does a good job clearly communicating the issue. With that said, I’m a bit embarrassed to say I had no idea Ward Cunningham coined the term and the video included in this article is an astoundingly clear way to describe it, and very different than I've ever heard in two decades in tech.

Ward is the original inventor of the "Technical Debt" term, and it's revealing to hear the sentence in which this metaphor was used the first time (emphases are mine):

If we fail to make the program aligned with what we understand to be the proper way to think about our [...] objects, then we are going to continuously stumble into disagreement, and that would slow us down like paying interest on a loan.

Ward describes debt as the natural result of writing code about something we don't have a proper understanding of.

He doesn't talk of poor code — which he says accounts for a very minor share of debt.

He talks of disagreement between business needs and how the software has been written.

This brought me back to Pragmatic Product Management, and making sure that you really know the problem you are trying to solve. If you don't, not only are you likely to create a poor solution, you are also almost certainly going to create technical debt.

Framing this metaphor this way is so much more powerful than how it is typically used.