“Technical Debt” is NOT the result of poor programming – it is the cost of not refactoring as you learn more about a solution.
Like all things popular, “Technical Debt” has become a widely misunderstood and abused term. In some cases, Tech Debt is everything done by those who have gone before, “OPC”: Other People’s Code.
Other times, it’s it’s assumed that Technical Debt is the result of some dumb decision, or some corner that was cut. It’s important to understand the metaphor, and be careful how you use it.
A bug or defect is not Technical Debt. Cutting corners on things like test coverage is not technical debt. Here’s Ward Cunningham (who coined the term Technical Debt), explaining where it came from and what he meant by it:
As you’ll see, the point is that as you learn about how the technology needs to work, that you need to go and iterate on the design. This is why we put “Build, Measure, Learn” and phrases like “Lightbulb to Learning Loops” at the centre of how we work.
Technical Debt is the result of failing to iterate as you learn. There simply isn’t a version of doing good product development where you do all the learning during a “design and analysis” phase and then just “execute” or “deliver” that design. Double Diamond be damned!