[resonious]

Out of curiosity, are you saying that most tech debt is systems that don't generate much value?

If you had asked me, I'd probably say that tech debt is mostly systems that do generate value but are built poorly or in a rushed manner. Deadlines creep up, devs crunch, they ship a "working" product but it has design flaws that manifest as technical debt.

But now that I think of it, I've definitely also experienced what you're mentioning (I think). I've worked on projects with questionable motives that ultimately end up cancelled or abandoned. The leftover code remains and continues to confuse newcomers.

[samus]

Sometimes, there is also functionality grafted to the wrong place in the system, or on to the wrong system. This can happen for a lot of reasons: expediency ("we have to foo the bar, why don't you implement it there as the release window is just right for our purposes"), bad design, or changing requirements.

If it stays there for too long, it will complicate the design of the underlying system because it has to be kept alive for daily business to go on. Such features are sometimes hiding in plain sight, and are actually causing a lot of pain or cause long-term risks, but we are too shy or spread too thin to address the issue. And why should we? After all, it works at the moment.