Fifth International Workshop on Managing Technical Debt

In conjunction with ESEM 2013


Fifth International Workshop on Managing Technical Debt

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:

  • Technical debt reifies an abstract concept
  • Technical debt is not simply bad quality but includes strategic architectural decisions
  • Technical debt can be introduced by context shift
  • Defects are not technical debt
  • Lack of process is not technical debt
  • New features not yet implemented are not technical debt
  • Technical debt implies dealing with both principal and interest
  • Technical debt assessment depends on future outcomes
  • Technical debt is not directly measureable
  • Technical debt should not be completely eliminated
  • Technical debt should not be treated in isolation from the software development context
  • Technical debt can be a wise investment

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.

Join us at the workshop

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.

  1. Register
  2. Tell us about yourself to help us plan the discussion. You might:
    • Say how you define technical debt and/or offer an example.
    • Explain your personal experiences and challenges you face dealing with technical debt.
    • Describe your ideas of techniques for managing technical debt.
    • Ask some questions on what puzzles you about technical debt.
  3. Gather your thoughts. You might question yourself and colleagues using this technical debt interview guide and share your insights

Background material

Site hosting by the SEI