There seems to be some confusion these days when it comes to the idea of tech debt and what it means for an organization. You can find a dozen articles and whitepapers on any given day that espouse working down tech debt at all costs, and they just so happen to be selling a solution to the problem for the low, low price of six bajillion dollars a year. Or, on the contrary, we have the Bob Ross School of Code that states there is no such thing as tech debt, only happy little accidents of code. But the problem is that I think both these extremes ignore what tech debt actually is and where it comes from; once we actually understand this can we begin to figure out if tech debt is even something we should be worried about in the first place.
Briefly put, tech debt is any code, system, automation, or widget that needs to be remade, rewritten, or no longer works as intended. Tech debt can take many forms: a vendor changing their API causing your integration to fail or throw warnings, tests that need to be written, deploying files to your VM’s that are no longer used but are part of a larger configuration dump so they’re just left there, and so much more. Simply stated, tech debt comes from the evolution of software, environments, or requirements, or from an engineer’s inability to solve a problem efficiently or satisfactorily. And from my perspective, the first type of tech debt — the one born out of evolution — is actually a good thing. It means you and the software you build are evolving, that the company that employs the software is growing or changing, and often that means growth is happening. No one is capable of designing the perfect system or writing the perfect code that never needs to be updated, never needs to be reconfigured, and will always adapt to every anticipated and unanticipated need. Expecting our developers to do the same and treating tech debt as something bad or a sign of bad performance is unfair to the professionals in our field and runs counter to the very interests of the business. To emphasize carrying little to no tech debt is to prioritize stagnation. Does that mean you shouldn’t focus on paying down tech debt? Of course not, but doing so shouldn’t be seen as menial or a sign that the code was written wrong in the first place, often it's the very opposite. It's the bits of code that are critical to the functioning of the company that tends to need the tech debt payment because its these exact stretches of code that keep the business running, and as the company evolves and grows its those functions that need to grow and evolve in turn with it.
Even the second kind of tech debt — the kind caused by an engineer's lack of experience or inability to come up with a more elegant solution to the problem — can be seen as a good thing under certain circumstances. If the engineer is able to come back to that problem in the future and solve it in a way that is better, fast, less time-complex, or better satisfies your KPIs or other metrics, that is then an indicator of growth and maturity on behalf of that engineer. That’s something you should celebrate! And, even if the one fixing it isn’t the same engineer as in the
git blame , the ability to pay down that tech debt should be seen as a sign of organizational maturity and growth as well. At the time when it was first written, if the engineer who wrote it was able to convince their tech lead or manager that this was the best way, that shows either your tech lead or manager didn’t have a better solution, didn’t know that they needed a better solution, or simply didn’t care enough to put much thought into it. However, now, if that debt has been identified and prioritized as something that needs fixing, then that clearly demonstrates the evolution of the development organization towards a more mature, more skilled, and more knowledgeable organization.
We are never going to be rid of technical debt; to say otherwise is like saying kids will never grow out of their clothes. It’s inevitable. But whether or not you view it as a bad thing or a growth thing is up to you.