A couple of nice articles about Technical debt.
In "Technical Debt Quandrant" Martin Fowler describes a model under which aims to classify the technical debt that is created during development. I'd like to think that the technical debt I create will mainly live in the top right Prudent-Deliberate box. I know that this has not always been the case though!
Technical Debt should be reserved for cases when people have made a considered decision to adopt a design strategy that isn't sustainable in the longer term, but yields a short term benefit, such as making a release. The point is that the debt yields value sooner, but needs to be paid off as soon as possible.
This lead me to an older article "A mess is not technical debt", by Uncle Bob, which describes what technical debt is, and more importantly what it isn't.
A mess is not a technical debt. A mess is just a mess. Technical debt decisions are made based on real project constraints. They are risky, but they can be beneficial. The decision to make a mess is never rational, is always based on laziness and unprofessionalism, and has no chance of paying of in the future. A mess is always a loss.