I agree with your point. Ward asserts that one should invest in refactoring a piece of (clean) code if your understanding of the business model that drives it b

I agree with your point. Ward asserts that one should invest in refactoring a piece of (clean) code if your understanding of the business model that drives it becomes more refined. This may or may not translate into more sustainable pace, however it avoids talking about the real killer of sustainable pace which is poorly written code. There certainly is value in refactoring poorly written code and I would love a metaphor that described that. As it is talked about in this blog post or by Ward I'm not sure I care at all about tech debt as a factor in software development - it seems like an interesting idea, but at best a minor productivity boost when compared to removing messy code. It seems we need to recognize that even with our best efforts we eventually crack and write something poorly. While it is painful to recognize this openly, it seems necessary in order for us to come up with ways to deal with it. We need to know why we end up writing such code, how and when to remove it, and how to sell our customers on the value of removing it without losing their trust and looking unprofessional.