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.
Here’s my definition of tech debt:
Tech debt is 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 “shortcut” to reduce time-to-market and gain a strong market share. It’s a business decision, a calculated gamble, so to speak.
So true tech debt, the “good” kind, is a compromise knowingly made on the engineering side of product-building in order to gain business advantage.
But what you’ll find is that the term “tech debt” is also used when addressing long-standing issues arising from bad programming practices or brittle & shallow design.
But those are just a fallout of poor hiring practices, inexperience and/or unprofessional engineering leadership. I believe this to be an incorrect usage of the term that just muddies the waters.
Here’s the $64,000 question:
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 here’s 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.”
So, the next time you use the term “tech debt”, think it through: Is this the “good” kind of debt? Or is it something else entirely?