- There's an implication that it should be 0, but anyone who's ever worked on a large enough project will tell you that any large project will have some technical debt. When you get down to practical implementation there's always tradeoffs that have no single clear answer
- There's this dissonance where the things that are called 'technical debt' are potentially serious enough to cause problems, but not serious enough for anyone to actually prioritize dealing with them.
Using the description 'aesthetics' makes more sense to me
- I think it's inherent that aesthetics has a subjective element and that there's no way to drive it down to 0 or 100 or whatever.
- I think it helps with prioritization by setting the right context. "Removing technical debt" doesn't sound like a particularly productive activity, but "improving aesthetics," while clearly not as high priority as, say, "improving functionality," at least carries the connotation that something will get improved as a result of the work, even if it's something not totally tangible.
What are HN's thoughts? Are there other words besides aesthetics or technical debt we could/should be using?
I think technical debt is accurate, because you don't pay down debt to 0. A certain amount of obligations is normal in a business. But you don't want it to compound and get out of control.
Alternatively you could say something like cruft or looming danger, if you see great damage coming to the business.
No matter what you call it, though, if teams aren't empowered/encouraged to make the code more habitable, it won't happen. You could call it "partying" instead of "removing tech debt" and folks still won't do it if the system around them discourages it ("must work on next feature now!").
If you really don't like the term debt, "technical hangover" sorta conveys the same idea.