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 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.

Yet many questions remain open, such as

• How do you identify technical debt? What are the different kinds of debt? What parameters 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 be empirically collected for developing conceptual models?
• How do you measure and pay off 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. 

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 presented at 2010 FSE/SDP Workshop on the Future of Software Engineering Research. The second workshop was held collocated with ICSE 2011. The program of that workshop can be found here. In addition, a summary of the workshop is available in the September 2011 issue of ACM SIGSOFT Software Engineering Notes.

The goal of this third workshop is to discuss managing technical debt as a part of the research agenda for the software engineering field, in particular focusing on eliciting and visualizing debt and creating payback strategies.

Submission Information

We invite submissions of papers in any areas related to the themes and goals of the workshop in the following categories:

1. research papers-describing innovative and significant original research in the field (8 pages)

2. industrial papers-describing industrial experience, case studies, challenges, problems and solutions (8 pages)

3. position and future trend papers-describing ongoing research, new results, and future trends (4 pages)

Contributors are requested to submit their papers through EasyChair. 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.All accepted papers will appear in the electronic proceedings of ICSE 2012.

Important Dates

Submission deadline: February 24, 2012

Notification to authors: March 19, 2012

Camera ready papers: March 29, 2012

The 3rd MTD Workshop: June 5, 2012