Much of what is called "technical debt" is more likely "technical junk." Technical debt has the ring of responsibility around it. As we build new services and maintain the others we tell ourselves that we have made reasoned judgments as to what to ignore for now:
• We don't need to update that library just yet, but we know not that falling too far behind the current version will make updating grueling and so will do it later.
• We don't rewrite a troubled module just yet, but we know the rewrite will relieve us from burdensome support and so will do it later.
• We don't replace the data design implementation just yet, but we know its scope has been exceeded and is now impeding enhancements and so will do it later.
• We don't broaden the testing regime just yet, but we know that doing so critically supports systems changes and so will do it later.
• We don't speed the ever slower, periodic, automated task just yet, but we know that task overlap has dire consequences for downstream processes and so will do it later.
• We don't hire additional staff just yet, but we know that additional staff is critical to efficiency and so will do it later.
Now, this sounds like technical debt and it is when you actually attend to it later. When you don't you have technical junk. The system and its data are patched, brittle, duplicated, lossy, slowing, and only though the sheer force of willpower can it be enhanced and maintained. Still, we continue to tell ourselves and our management a compelling story of progress on the two-fronts of enhancement and maintenance.
Update, 2018-10-26: Anecdotal slow motion story The Drift Into Technical Bankruptcy.