Technical Debt is a term used in programming to describe the situation where the refactoring of a specific programming decision will cost more in the long run than accomplishing the task properly immediately. While the decision saves time in the short term, it actually takes more time to support the decision in the long term, and thus creates "debt".
The term was coined by Ward Cunningham and is
described by Martin Fowler as:
You have a piece of functionality that you need to add to your system. You see two ways to do it, one is quick to do but is messy - you are sure that it will make further changes harder in the future. The other results in a cleaner design, but will take longer to put in place.
EditChallenges to the Technical Debt Idea
Eric Ries
challenged the popular understanding of technical debt on his blog in July 2009. His basic challenge is that technical debt will not always come due. Sometimes technical debt is incurred that will never have to be paid back. He argued that taking on technical debt that is unlikely to come due and is simultaneous of low-effect throughout the entire application can be advantageous in the long run, and the "all-or-nothing" approach to technical debt that most developers have is erroneous and needs to be approached with a bit more humility.