I don't think that "mess" is a good synonym for tech debt.
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.
it makes you look like you take on debt without reading term sheets.
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.
I do make the assumption that the reader is trying to look competent to their boss/clients yes. If that's not the reader's goal then I have very little to offer.
I don't think that "mess" is a good synonym for tech debt.
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.
Author here. Do you generally find that people who are not software developers understand what you mean when you say "technical debt?"
it makes you look like you take on debt without reading term sheets.
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.
I do make the assumption that the reader is trying to look competent to their boss/clients yes. If that's not the reader's goal then I have very little to offer.