How to use the term technical debt to mean anything you want
badsoftwareadvice.substack.com
badsoftwareadvice.substack.com
As opposed to other words and terms, which were readily found in nature?
Of all the examples he gives to make it sound like it's a meaningless term, only "when a developer doesn’t like the way something works and wants to change it for reasons they can’t explain and that are completely disconnected from reality" is a bad fit for the term.
It’s a shame, because the original meaning of cutting corners for genuine business reasons (time to market etc.) actually makes a lot of sense.
The real question is whether it is actually debt we are talking about. A developers hurt sense of code aesthetics isn't technical debt, but e.g. if code uses an ugly hack it can bite you performance wise, or when something is added or changed. When code is never maintained the libraries used can expose known weaknesses to the world etc.
> when you make an engineering decision that makes sense at the time, but then conditions change, and the way you handled the tradeoffs makes less and less sense every day, and you need to change the system to be more in line with the current constraints.
> when you create Version 1 of a system very quickly, and this creates a business but not more jobs so that people can help you work on the system.
The other definitions might be used by people to obfuscate bad work, such as this one:
> when you build a system and about halfway through, realize that the architecture is not going to work, but you just keep going, and from that moment on, rather than call it regret, you call all your work technical debt.
Similar to the last definitions:
> when you don’t like the way something works and want to change it for good reasons and are asked to explain it, and you use all the usual metaphors like system upgrades or migrations or legacy migration
This one even gives examples of misusing other terms.
So the next article will be about the word "migrations"?
If this happens frequently, this is an organizational problem.
People should use words in good faith and knowing what they mean.
---
I have no doubt that there are people talking like this but every term like this can be misused.
IMO, "technical debt" is a useful categorization for tasks.
Involving multiple team members when categorizing tasks might help to avoid weaponizing terms like "technical debt" in an unfounded way to impose subjective preferences.
That being said, not caring about actual technical debt is still a very prevalent problem, so this article seems a bit fluffy to me, arguing against strawmen.