Delivering complex, large-scale systems faces the ongoing challenge of how best to balance rapid deployment with long-term value. From the original description—"not quite right code which we postpone making it right"—various people have used the metaphor of technical debt to describe many other kinds of debts or ills of software development, encompassing broadly anything that stands in the way of deploying, selling, or evolving a software system or anything that adds to the friction from which software development endeavors suffer: test debt, people debt, architectural debt, requirement debt, documentation debt, or just an amorphous, all-encompassing software debt. Consequently, the concept of technical debt in software development has become somewhat diluted lately. Is a new requirement, function, or feature not yet implemented "requirement debt"? Do we call postponing the development of a new function "planning debt"? The metaphor is losing some of its strength on one hand. On the other hand, the practitioner community has increased interest to understanding and managing debt. As the pace of software delivery increases and technology rapidly changes, organizations need better guidance on how to insure the sustainability of their software development effort. This is evidenced by the large amount of discussion of the concept of technical debt in the blogosphere, and in particular in the agile software development arena.