Tech Debt Isn’t A Bad Thing
Not always, at least
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…
