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.
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.
International Workshop on Managing Technical Debt is seeking papers on practical experience with technical debt, and approaches to evaluate and manage technical debt including, but not limited to the following topics:
* Techniques for eliciting technical debt
* Visualizing technical debt
* Analyzing technical debt
* Measuring technical debt
* Relationship of technical debt to software evolution, maintenance and software aging
* Economic models for describing technical debt
* Technical debt and software life-cycle management
* Technical debt within the software ecosystem
* Technical debt and architecture
Find more information on http://www.sei.cmu.edu/community/td2013/