Technical debt was first defined by Ward Cunningham as:

"Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite... The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise." - Wikipedia

I think Ward had it right, like that's a big surprise. Technical debt is like taking a loan out from a loan shark. You borrow at high rates and hopefully for a very short time. If you don't pay it back quickly you will end up paying a lot more over time. Making small payments on the debt will help but until you get it down to a very small sum, or zero, you have the issue of compunding interest.

What this means for solution development is that every time you take that short cut in the name of saving time, make a design decision that is "not the way it should be done", or not keeping vital documentation up-to-date you are incurring technical debt. All of these choices make the system more fragile, less maintainable, and more costly to run. This debt burdens a system until it is repaid. In some cases the debt becomes so high that the application is declared bankrupt and it is liquidated, that is it is replaced.

It does not take a lot of technical debt to start the bankruptcy process. When code becomes too fragile, the design too complicated, or too little documentation for the decision to be made to replace a solution rather than fixing it. A small amount of technical debt on even a single piece of code can lead a developer to not want to alter it because they don't understand it or are afraid of what the changes might do. This leads to "work arounds" such as creating new code for the specific condition the developer needs to deal with. This is typically implemented with some type of "if...then" block of code. Now we have two pieces of code that do practically the same thing. This makes the system even less maintainable and increases the technical debt.

The best way to deal with technical debt is recognize that it exists, track it, fix it, and then figure out how to fix the process so it doesn't happen again. This is a typical Six Sigma approach to quality issues. If a team tracks the decisions that lead to technical debt you not only track that it is out there but also give them the tools they will need to analyze how to prevent it in the future.

Make sure that you point out to management and your customers that you made some decisions during implementation that sere sub-optimal. Make them aware that not repaying the debt will lead to even higher balances int he future and a fragile system. This has to be expressed in business terms such as business lost productivity, unplanned outages, and increased support costs to name a few. If you can't convince them of the urgency of repaying the debt keep the list of technical debt around. Sooner or later they will come back to you and talk about a problem that you can directly relate back to the technical debt that you have on your list. this is an excellent opportunity to politely bring up the topic of technical debt again. Sometimes we don't succeed the first time we talk to them about technical debt but sooner or later you will get through!