Delivering complex, large-scale systems faces the ongoing challenge of how best to balance rapid deployment with long-term value. The technical debt metaphor is gaining significant traction in the software development community, as a way to understand and communicate issues of intrinsic quality, value, and cost. 

The idea is that developers sometimes accept compromises in a system in one dimension (e.g., modularity) to meet an urgent demand in some other dimension (e.g., a deadline), and that such compromises incur a debt on which interest has to be paid and which should be repaid at some point for the long-term health of the project. 

The technical debt metaphor was coined by Ward Cunningham in his 1992 OOPSLA experience report in defense of relentless refactoring as a means of managing debt:

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.

Little is known about technical debt, beyond feelings and opinions. The software engineering research community has an opportunity to study this phenomenon and improve the way it is handled. 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 when their consequences start slowing projects down.
• Software development decisions, especially architectural ones, need to be actively managed, continuously analyzed quantitatively as they incur cost, value, and debt.

Yet, it leaves many questions open, such as

• How do you identify technical debt? What are the different kinds of debt? What are its parameters that help projects elicit, communicate, and manage it?
• What is the lifetime of technical debt?
• How is technical debt related to evolution and maintenance activities?
• How can information about technical debt empirically be collected for developing conceptual models?
• How do you measure and payoff technical debt? What metrics need to be collected so that key analysis can be conducted?
• How can technical debt be visualized and analyzed?

There is increasing necessity to address these questions. Theoretical foundations and empirical evidence for analyzing and optimizing short-term versus long-term goals in large scale projects are needed. 

Second International Workshop on Managing Technical Debt (MTD 2011)

This workshop proposes to put managing technical debt as a part of the research agenda for the software engineering field. Our goal through this workshop on technical debt is to bring together leading researchers and practitioners for the purpose of exploring the open questions.

An initial workshop was held at the Software Engineering Institute in Pittsburgh on June 2–4, 2010. The outcomes of this workshop and open research questions are outlined in the position paper Managing Technical Debt in Software-Reliant Systems that will be presented at 2010 FSE/SDP Workshop on the Future of Software Engineering Research. Relevant topics of the workshop include, but are not limited to, the open questions and challenges summarized in this paper.

Submission Information

Please submit your paper online at through CyberChair Pro at http://cyberchairpro.borbala.net/mtdpapers/submit/.

We invite you to submit original and unpublished position-and-future-trend, research, and industrial papers. All papers should conform to the ICSE submission format and guidelines, ACM SIG Proceedings Format, and should not exceed the suggested number of pages indicated below.

1. position-and-future-trend papers—describing ongoing research, new results, and future trends  (4 pages)
2. research papers—describing innovative and significant original research in the field  (8 pages)
3. industrial papers—describing industrial experience, case studies, challenges, problems and solutions (8 pages)

Each submitted paper will undergo a rigorous review by three members of the Program Committee. All accepted papers will appear in the ACM Digital Library.

Important Dates

• Paper submission: January 28, 2011
• Notification of acceptance: February 18, 2011
• Camera-ready: March 10, 2011
• Workshop: May 23, 2011

.