What is the definition of technical debt?
The Technical Debt Metaphor is meant to evoke an analogy to Financial Debt.
Financial Debt can be used as a tool to bootstrap a business: you need machines to make money, but you need money to buy machines. You break this catch-22 by taking out a loan to buy machines, and then repaying the loan using the money you gained using the machines.
Technical Debt can be used as a tool to boostrap your understanding of the domain: you need to play around with the software to figure out what it's all about, but you need to know what it's about to write the software. You break this catch-22 by writing the software as best as you can using the partial understanding you have currently, then rewrite the software using the understanding you gained from playing around with it.
Just like Financial Debt, Technical Debt needs to be small, needs to be paid back, and it accumulates interest if it isn't paid back.
It's very important that Technical Debt is a tool for understanding. It is not an excuse for bad code, bad design or bad decicions. It is not about getting a product out of the door.
It is about getting experience. (Note that getting a product out of the door might very well be a prerequisite to getting experience, but it's not what Technical Debt is about.)
Ward Cunningham originally coined the term when he was explaining to his boss why refactoring was important. The software they were working on was financial software, the company was a financial company, the boss was a finance guy, so he used a financial metaphor.
Since you specifically asked about a definition, here's mine:
Technical Debt is the difference between your current understanding of the domain and the understanding that is reflected in the current version of the software.
It pretty much means the bad design choices made during software development in order to get a product out of the door.
The idea being that you will "pay the debt" later on and fix the bad design when you have the time.
Wikipedia has a more detailed explanation.
The original term was coined by Ward Cunningham, and the idea is that if you cut corners in the short term, you’re borrowing against the future maintainability of the software and that at some point, not unlike a credit card, you’ll pay down that debt by going back and fixing the hacky solutions that were put in place.
See the blog post here for more information and how to mitigate it:
Technical debt is the result of trading code quality for something else you deem more important at that moment. It can be going to market fast to get feedback. It can be shipping a vulnerability patch quickly. It can be focusing on doing one (other) thing well.
Technical debt is a conscious tradeoff. It's different from making a mess.