I agree with you but I think there is something to the business side. No Sales/PjM/Manager/CFO is likely to want to spend 3 months of resources on non-revenue generating updates. They would rather pay the fiddler when the system has a failure. Just like us humans, people don't change their diet and exercise until AFTER the heart attack.
I'm not actually arguing against prioritizing shipping. My criticism is with the way that people wield language to enforce their choices and avoid responsibility.
Defending a choice means actually defending it.
"If we don't ship this by X date, there won't even be a company to have the problem you're talking about."
"This choice will have less impact than you think for X reasons."
The problem is the specific reasons are often more in the family of "Shipping this is one of my KPIs and I'll be on some other team when the problems you're talking about are realized."
It's not just business vs. engineering anyway. Slow to ship? It's cause of all the tech debt. No tests? It's okay, just tech debt. No docs? Poor abstractions? Lack of understanding about the problem? Low skill with the technology at hand? It's all fine! Tech debt can be your scapegoat or hall pass for anything.
I don't quite agree with the 'for anything'. For poor/missing technical assets that area direct cause of insufficient upfront investment (of time, money, etc), that's 'tech debt'.
Missing/outdated docs/tests? Tech debt.
"Low skill with technology" - probably not as easy to lump it as 'tech debt', imo.
"Lack of understanding about the problem" - again, doesn't seem like tech debt, but... business debt. Tribal knowledge debt. Operational debt, but not explicitly 'tech' debt.
But... perhaps that's your point? It's easier to just say 'tech debt' for everything, even if it's plainly the result of underinvestment on non-tech things?
