Let's not call it "tech debt," it's just "mess"

Martin Fowler wrote about the technical debt quadrants, and "mess" seems to cover 1/2 to 3/4 of the quadrants. I don't think it accurately describes the case where you need to deliver quickly and knowingly accept the consequences of less-than-optimal decisions.

There's also no reason for teams not to track their technical debt. Although some kinds, like what Fowler refers to as the inadvertent side of the spectrum, may not be known right away, you can at least track the need to correct deliberate poor choices. Traceability to architecturally significant system elements or user-facing features can help account for where the debt lives and how it may impact future effort.

The metaphor of debt isn't perfect, but calling it "mess" is even further from reality.

That is exactly the case 80% of the time, knowingly bad decisions to solve unrelated concerns. The most common scenario is over reliance on abstractions to increase candidate availability at hiring.