I'd like to quibble a bit with the definition of technical debt being used. A decision not to refactor code when you don't know if you will be improving it is

I'd like to quibble a bit with the definition of technical debt being used. A decision not to refactor code when you don't know if you will be improving it is not technical debt in my book. There are many times when I look at a piece of code and say, "This is a smell here, but until we know better what we are building I can't remove the smell". It actually would be technical debt if I covered up the smell with something pretty that wasn't related to what I actually needed. Later on I'll have to remove that pretty code (or work around it). Hopefully making me feel better about apparent lack of smells is worth it ;-) The idea of technical debt is that you are trading some kind of completeness/correctness in the code for something else that is valuable. Usually that valuable thing is time, but it can be something else. For example, perhaps you know that your requirements are wrong. However, the client is unhappy with answering questions. You could pester them some more, or you could implement the obviously wrong requirements and wait for them to find the problem themselves. In this way you defer the frustration of your client to a later time when they might be more approachable. It should go without saying that you should almost never do the above: I'm only using it as an example of tech debt that isn't to do with saving time. There are lots of times where technical debt is beneficial. The key is to understand the cost/benefit. This is where we usually go wrong. The cost/benefit analysis is usually done by someone who only understands the benefit. It's just making the analysis of borrowing money and making the assumption that you don't have to pay it back. Hmm... how much money should I borrow in that case? Obviously, as much as I can get!