In conjunction with ESEM 2013
Co-located with the Empirical Software Engineering International Week (ESEIW 2013)
Technical Debt is a metaphor that is gaining importance because it is well-received among practitioners when thinking about the quality of software. Technical debt lacks a formal definition; it can be seen as the invisible results of past decisions about software that negatively affect its future. The reference to financial "debt" implies that understanding and managing tradeoffs between short-term benefits (e.g., time to market) and long-term costs (e.g., maintenance) is central to the concept.
Technical debt provides a useful means to map practical problems to research questions and hence drive the direction of future research efforts. Technical debt provides a context-dependent way of thinking about software quality across lifecycle phases that lend itself to quantitative analysis and hence objective observation. Thus, it provides us with a useful framework for guiding all kinds of empirical work (especially the reminder to measure not only instances of rework but the opportunity costs should that rework not be performed) and effectively transmitting the results to practitioners (by recognizing the existence and rational management of tradeoffs).
As an outcome of the discussions during the most recent techical debt workshop, co-located with ICSE 2013, Steve McConnell's definition of technical debt served as a useful starting point:
"A design or construction approach that's expedient in the short term but that creates a technical context in which the same work will cost more to do later than it would cost to do now (including increased cost over time)."
We refined this definition with the following criteria:
Increasing industry interest and emergence of organization specific practices can be seen as an early indication that industry needs a clearly defined practice to deal with issues such as evolution, strategic resource management and bridging the stakeholder communication gap. As we slowly converge on a crisper definition of technical debt that does not include all software development ills, and as we understand more the boundaries of the metaphor, there are numerous challenges ahead.
Our goal through this 5th workshop on managing technical debt is to bring together leading empiricists and practitioners for the purpose of exploring practical problems to provide opportunities for research that can provide evidence for or against the emerging definition and the efficacy of emerging practice.