I agree with your assessment. Using the language "tech debt" makes it appear that there is a correct way to design something and that if you're not doing it tha

I agree with your assessment. Using the language "tech debt" makes it appear that there is a correct way to design something and that if you're not doing it that way, you will need to pay a debt on it, now or later. The reality is it's all trade-offs and sometimes those debts never need to be paid at all. "Bad code" that is reliable within the constraints it is exercised and that is isolated may appear to have to tech debt, as in "if we changed the design, we could support XYZ feature" but if XYZ feature never materializes, it's a waste of time to touch it. Maybe we can come up with more appropriate language for this? Something akin to "inflexible" code. Calling something "debt" assigns too much subjective value to it while making it seem objective.