An engineering perspective on Tech debt
One of the inescapable realities of enterprise software is the necessity of facing down tech debt. But what exactly is it? Is it always something to avoid? The central issue here, of course, it how you define this term.
My definition of tech debt is this: it's the ongoing technical impact of business decisions made in order to secure a market advantage. Tech debt functions just like the availability of credit to a growing business, providing it with a much-needed boost during it's rapid-growth stage. Sometimes you've got to take on a calculated amount of tech debt to reduce time-to-market and gain a strong market share. It's a business decision, a gamble, so to speak.
So true tech debt, in my opinion, is a compromise knowingly made on the engineering side of product-building in order to gain business advantage. Please don't use this term when you address issues arising from bad programming practices or brittle & shallow design. Those are just a fallout of poor hiring practices, inexperience and/or unprofessional engineering leadership. Can the engineering burden you are facing down be explicitly tied to decisions made in order to gain a business advantage? If so, then you are now "paying back" tech debt by setting things right. If not, it's not tech debt at all -- it's just cleaning up a mess you (or someone else) made.
And the final word from Ward Cunningham's explanation: "... the ability to pay back debt, and make the debt metaphor work for your advantage depends upon your writing code that is clean enough to be able to refactor as you come to understand your problem."