Tech debt works great when it's done on purpose, and when the people/management who take it on are the same one who eventually deal with it. It takes a level of organization maturity to do that though.
What unfortunately happens a lot is orgs taking on tech debt without realizing it (devs are too junior, or management doesn't listen to devs, or various other reasons). Then 1-2 years later, the system is falling apart and the old engineers are gone. The new ones just call it tech debt as this kind of unavoidable force of nature that was dropped on them (because it kind of was).
Or worse, the devs of old ARE still there, but pretend that after 1-2 years, its inevitable for a system to be falling apart and needing to be rewritten from scratch.
This level of industry immaturity prevents the tech debt concept from fully working.
In organization where tech debt IS a fully thought out and planned out compromise to get value today at some cost to be paid off later, then yeah, it not only works: it's often the right thing to do.
In most orgs like this that I've seen, it leads to a fundamental misunderstanding of tech debt.
Messy code is painful so the answer is sought, when we don't have much experience, in what we learned in classes and books: elegant abstractions. But we end up abstracting business logic in such a way that when the business needs to change, our code can't change with it, and that's when we have true tech debt of the "let's rewrite the world!" sort. It might be beautifully designed abstraction, but if it's tied to the features of yesterday too much, it's going to become increasingly brittle and painful.
Now when someone says "we can ship this sooner but it'll be hacky and introduce tech debt to make the code re-usable" I'm much happier, and would rather have the code not be intended to be re-used until we prove that we understand how we'll want to use it next time.
Not just that, source code should really be viewed as a toxic byproduct, the more of it you generate, the more you're going to be paying in maintaining and managing it. The best code you can write, is the code that meets your current needs in as succinct a way as possible. Further anything that's internet facing is even more critical to minimize, failure to properly deal with it (keep it up to date and stay on top of known vulnerabilities) can and will sink a business when that bit rot eventually leads to an Experian type situation.
What unfortunately happens a lot is orgs taking on tech debt without realizing it (devs are too junior, or management doesn't listen to devs, or various other reasons). Then 1-2 years later, the system is falling apart and the old engineers are gone. The new ones just call it tech debt as this kind of unavoidable force of nature that was dropped on them (because it kind of was).
Or worse, the devs of old ARE still there, but pretend that after 1-2 years, its inevitable for a system to be falling apart and needing to be rewritten from scratch.
This level of industry immaturity prevents the tech debt concept from fully working.
In organization where tech debt IS a fully thought out and planned out compromise to get value today at some cost to be paid off later, then yeah, it not only works: it's often the right thing to do.