Tech debt is a poor name, use tax instead - here's why
The term “tech debt” is not doing us engineers any favours. It is as ambiguous and misleading as the word “legacy”. Of course we can find definitions that state otherwise, but both sound like there was a mistake made, something preventable, as opposed to something inevitable.
It also sounds like something you created, instead of upfront investment everyone needs to make to keep things running smoothly. Everyone wants to escape the negative vibe and ends up ignoring the only productive meaning of the word - that you’ve gotta pay it off.
Naming determines how people interact with the concept - if something is not a bad thing, don’t use a negative noun/verb to describe it!
The word debt tells us nothing about what we’re supposed to do about it. Every company, department, team ends up having the same discussions over and over again. Pay it off, but when, and what is the penalty for not paying it off? How can we communicate to our stakeholders that it will never be paid off?
Tax answers all these questions - we pay it off with every ticket. Developers discuss the tax before the work starts and determine it based on the component and the changes made. For example
- active development, moving fast, haven’t seen the best structure yet? - low tax, let’s keep rolling
- something with the component has caused trouble for a few iterations? - raise the tax
- project has been on the shelf too long? - high tax.
- the unit you’re supposed to change has large functions, custom scripts, zero unit tests? - double it
Running from the inevitable just complicates things. When you incorporate something like a tech tax in your routine, everyone simply gets used to the fact that that’s how things are. No more hesitation and guilt preventing you from mentioning things that are necessary (and not your fault). And who knows, you might even have a glimpse of how build output looks without all the deprecation warnings.