Don’t call it technical debt unless you’re going to go back and fix it. Otherwise, you’re just giving the team permission to do things the wrong way.

InfoWorld is a source of news, analysis, and commentary on technology trends, IT strategies, and business innovation. With a focus on enterprise technology and digital transformation, InfoWorld offers insights and guidance for IT decision-makers, software developers, and technology professionals. From  articles on cloud computing and cybersecurity to product reviews and industry trends, InfoWorld helps readers navigate the complexities of modern IT environments and make informed decisions to drive business success.

InfoWorld

Technical debt is often misused as an excuse for poor coding practices. Originally, it represented deliberate decisions to write sub-par code temporarily, with a plan to address it later. However, it has become a label for all bad code, which can stem from accidental complexity or rushed development. To reclaim its true meaning, only code with a planned fix should be labeled as technical debt. Anything else should be recognized as code rot.

Technical debt is just an excuse

It does not always make sense to have this split. If you have some code, that is “bad”, and needs to be fixed - does it matter if it was done on purpose, or just because of the lack of skill of the dev who wrote it? I don’t think it does.
Another problem I have with the split is, that quite often, after a year or two after the “bad” code was written, it will be picked up by someone else, and you might not have the knowledge why it was done this way. Of course, there are some obvious cases were you see that code was just copy-pasted from stack overflow, but in many cases you could wrongly assume its “code rot” as you called it, but in fact they did something on purpose and you should at least try to to figure out the reason for such a decision. Thankfully, ADR are getting some popularity :)

Oh we invented new term for technical debt, so we can blame lazy coders about it

Debating the meaning of “technical debt” distracts from the real issue: a lack of code ownership and oversight. It’s easier to argue semantics than to confront organizational negligence.

If you ever hear someone say “this is a quick fix and I will get back to it later”, 99% of the time, they never get back to it.