TD 2013 - Fourth International Workshop on Managing Technical Debt

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.
Theoretical foundations and empirical evidence for analyzing and optimizing short-term versus long-term goals in large-scale projects are needed. We can offer software engineers a foundation for managing such tradeoffs based on models of their economic impacts. Technical debt succinctly communicates the issues observed in large-scale, long-term projects:
There is an optimization problem where optimizing for the short-term puts the long-term into economic and technical jeopardy when debt is unmanaged.
Design shortcuts can give the perception of success until their consequences start slowing projects down.
Software development decisions, especially architectural ones, need to be actively managed and continuously analyzed quantitatively as they incur cost, value, and debt.
Submission Information
We are 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
Papers must conform to the ICSE 2013 formatting and submission instructions. Submit your paper electronically via Easychair. We invite submissions of papers in any areas related to the themes and goals of the workshop in the following categories:
research papers - describing innovative and significant original research in the field (8 pages)
industrial papers - describing industrial experience, case studies, challenges, problems and solutions (8 pages)
position and future trend papers - describing ongoing research, new results, and future trends (4 pages)
Submissions should be original and unpublished work. Each submitted paper will undergo a rigorous review process by three members of the Program Committee. All types of papers must conform to the IEEE Computer Society Formatting Guidelines as announced by ICSE submission format and guidelines. Please use either the Word Template or the LaTeX package provided by IEEE CS.