It's poor decisions early in the project that make it harder and harder to add features and fix bugs reliably and quickly. And, like debt, it has a compounding effect upon the rest of the project.
I wouldn't say it's necessarily "poor" decisions, though it often is.
To extend the metaphor in the cartoon, maybe you had three minutes to produce a demo cart and close the sale, and that was enough time to put holes in some square tiles, but not to machine round wheels. In that case it's not a technically good choice to use square wheels, but it is arguably a prudent one.
Indeed, technical debt can be there for whatever reason.
It could be that idiot coder who caused a lot of damage in the code before someone finally checked what he did.
It could concern old code created by otherwise sensible programmers at a time when it just wasn't clear how something should work.
It could be a matter of something that was once a good pattern, but by the introduction of something newer has become technical debt (although you mostly would call this just "old code").
And indeed, sometimes you have to hack something in because there's this customer of manager who DEMANDS that something happens NOW.
In general technical debt is basically bad code that when left unfixed will do more damage over time and will often end up costing you more than the times it takes to just fix it.
"I want results, not excuses!"
"I am paying you for stuff that works, not fancy acronyms!"
"Let's do it the way that works today and we can sort out the exceptions Tomorrow™"
Funny. Also interesting the degree to which us programmers are obsessed with this. Not technical debt itself, but technical debt the metaphor.
There seems to be an unlimited supply of blog posts outlining the finer points of the metaphor like who is the bank, which project management concept correlates to your credit rating, and so on.
