Stop paying tech debts, start maintaining code
Tech debt is a term that’s tossed around a lot in software. I haven’t worked at a company that didn’t talk about tech debt. I haven’t been on a development team where its product owners weren’t in some kind of tug-of-war with the devs over mounting tech debt. It’s a permanent fixture in the software industry. A fixture I don’t think is well understood by either side.
To that end, I want to accomplish a few things in this article. I want to provide a frame shift on tech debt. I use frame shift as a way to say stop using the term Tech Debt! I also want to break down some meaningful, practical, day-to-day ways to discuss and practice software maintenance.
The term debt is an abstract concept for a lot of folks. It’s hard to reason about. You spend money that you don’t currently have, but then you need to pay it back, often according to complex terms, at a later date. To me, that doesn’t relate to writing code. Code written is not something to be paid back.
That gets us to the core of the issue I have with the term Tech Debt. I’ve been searching a long time for a definition that my peers and I can use to gain a shared understanding of what we’re talking about when we trade tech debt around.
