Often when people are talking about the concept of technical debt in software, they relate it to cleaning up “quick and dirty” code. I'm not convinced that this is what Ward Cunningham was really talking about when he first coined the term.

To me, technical debt is the natural, inevitable result of evolving requirements. Code that was perfectly written to model the requirements as they were known two months ago, may detoriate and become inadequate or even incapable of supporting the implementation of todays requirements. This is really the essence of Agile software development: We write code to model the world as it is known today, with less regard for what may be known tomorrow. Then, as we discover more knowledge, we pay back the debt we owe for the assumptions we made by remodelling and refactoring the code.

So please don’t think that you can use technical debt as an excuse to write quick and dirty code that you’ll come back and “fix” later. Paying back technical debt is about keeping your code clean – which implies that it was, in fact, clean to begin with.