Why We Need to Stop Lying About Technical Debt
It wasn't until I was well into my career and way after my tenure at AT&T that I was exposed to the phrase "tech debt". In the context that was presented to me, it seemed like a convenient way to explain away coding sins of the past without actually taking responsibility. I have started taking a firmer stance on what I do and do not consider as technical debt at the startups that I work for.
If you have ever made a large purchase - such as a car or house - you're well aware of the hoops you're required to jump through and all the red tape that must be navigated. If you haven't had the opportunity to do something as stressful as purchasing a house in the United States I'd encourage you to read Lending Tree's article on minimum mortgage requirements. Needless to say, debt is definitely something that is very deliberate and is taken very seriously. The loan process is controlled by laws, regulations, rules, best practices, and piles and piles and piles of paperwork; it's very strange to come across someone who has "accidentally" accumulated a large amount of debt.
What does getting a mortgage have to do with technical debt? I feel that both should be carefully considered, they should be bounded by time, they must be heavily documented, and both are required to carry some form of interest payments. It is not correct to simply label every issue or system that needs to be refactored as tech debt. I've seen entire applications scrapped because they had too much "tech debt" only to be replaced by systems with the exact same issues. Instead of being scrapped I feel someone should have taken a closer look at why these applications were malfunctioning and fixed the issues: maybe requirements weren't clear enough, maybe the wrong platform was used, maybe the engineers were trying to solve the wrong problem.
Using this perspective, what constitutes as technical debt? A conscious decision to take a technical shortcut with the acknowledgement that there will be increased maintenance burden and the shortcut will eventually need to be rectified. I have even enacted a process where the code is explicitly commented and the README is updated with the date and an acknowledgement of the tech debt. Anecdotally, this process has had the unexpected side effect of reducing the amount of technical debt that I've seen in newer systems. I'm not sure if this reduction is a result of the tighter definition, or the added trouble of having to explain the shortcut to me and then having to write accompanying documentation - engineers don't exactly love being forced to write documentation.
Technical debt isn't bad, it is a necessary part of the high-tech startup process. It is not, however, the reason for all of a startup's woes. If you keep the definition for tech debt specific and make a habit of acknowledging it as it happens I feel like you'll have a much easier time paying it off in the future.
Good luck and I hope you're technical debt has a low interest rate!
-Sethers
