My preferred definition of technical debt is:
Technical debt is existing (technical) structures that stand in the way of making the next change. The interest is the cost of having to deal with those structures in your day-to-day work, and the down payment is the cost of making the structures apt for use.
Debt can be intentional in that you take shortcuts to meet an important deadline or to hit a market window. In this case you have an expected ROI for the loan you take, one that you hope will pay off more than the cost of later fixing the shortcuts taken.
Debt can also be the unintentional, and here it gets interesting. One type of debt is that which results from sloppiness, usually resulting in a messy code base. This type is not related to any kind of investment, hence there is no expected ROI, it is just like a loan for consumption of drugs; it will destroy you (your code) and your economy if it doesn’t stop.
By the definition above, debt can also be the result of external events, sometimes out of your control. Your perfect system can suddenly become your largest debt if you go from one to several customers, the company strategy changes, the market changes or laws change.
Some people, among them Uncle Bob in this article, argues that messy code is not debt. I disagree, for the reasons above. I think Uncle Bob and others confuse debt that results from loans taken to make an investment, and debt resulting from neglect, lack of experience or incompetence. The cause is totally different, but you’re still in debt.
There is no reason to make a messy system, since there simply is no return on that investment. Accept debt only to take loans that enable you to make a sound investment.
Thoughts of a Goldfish by Daniel Brolund 
Sep 23, 2009 @ 21:04:45
To me it seems you and Robert Martin are quite in agreement. There’s a huge difference between dept as a result of neglect and dept as a result of calculated decisions. Both of you want to ban sloppiness and dropping of principles of the craft that we believe in. One way of not allowing mess to use the technical debt label as “shelter” is to refuse to call it technical debt and instead call it mess. Mess debt?
Sep 23, 2009 @ 22:05:38
I would say a mess is a bad sort of technical debt. If you shelter mess-making with technical debt you have other problems that won’t be solved with a different name.
Sep 24, 2009 @ 01:13:00
While I agree with both you and Uncle Bob in your views, and I enjoyed reading your posts, when it comes to definitions, when unsure, I tend to look up the original meaning of the term in question and think from that point further.
DEBT
According to Google, debt can be defined as:
“- the state of owing something (especially money); “he is badly in debt”
– money or goods or services owed by one person to another
– an obligation to pay or do something…”
TECHNICAL DEBT
Uncle Bob makes the difference between mess and technical debt based on the cause of it. But, debt is defined as a STATE only, so I would totally agree with you IF “technical debt” would be just a debt in technical domain, so to say. But – my understanding is that’s not the case.
Ward Cunningham coined the metaphor “technical debt” with a slightly different meaning, which, (again – how I understand it), is in line with Uncle Bob’s article (writing a messy code is not the same as making a rational choice of taking on a technical debt). So, the definition of technical debt is not only about the final state, but also about the reasons for ending up there.
Ref: http://www.youtube.com/watch?v=pqeJFYwnkjE (esp from 3:17)
Sep 24, 2009 @ 07:15:00
In other words, the exact same code is technical debt if there was some sort of decision of how to get it there, but not technical debt if it just happened?
I think that is splitting hairs. You still need to deal with it and eventually (probably) fix it. It has all the same characteristics. The difference is not in the debt, it is in what caused the debt and what you can (or can’t) do about it, and that is my point.
Sep 24, 2009 @ 11:54:00
I think that the wrong word was used in the metaphor in the first place, by Ward.
If a definition is not intuitive, and needs quite a bit of additional clarifications, it is questionable. It is not intuitive that debt as a state becomes state + cause for it.
It would be interesting to find the correct metaphor, that would describe just what Ward Cunningham meant, clearly and with no space for misinterpretations.