Martin Fowler gave a good description of technical debt in February of 2009:
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.
The metaphor of technical debt was used by Ward Cunningham in a 1992 experience report:
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.
Technical debt should not only be measured in terms of the trade-off between how thoroughly work is done now and how maintainable it is in the future. We should also measure technical debit in terms of how much effort is required to move some one new onto the team.
There are things which can’t be avoided when adding new people. The developer needs to know the language, may need to learn how to use a specific device, and may need to wait for parts to be delivered. But there are other things that shouldn’t require any effort. How hard is it to setup the project’s build environment? How long does it take to build the overall project? Are there tests to ensure that the working environment is functioning properly? Are there unnecessary IT infrastructure hurdles? Is the code organized well and documented well, or will the new team member have to waste time searching for functionality in a disheveled code base that lacks an accompanying narrative?
Inspect your current projects; do they require interest payments on technical debt when adding new people? Consider reducing the cost of moving people onto your program.