17.04.16 - 22.04.16, Seminar 16162

Managing Technical Debt in Software Engineering

Diese Seminarbeschreibung wurde vor dem Seminar auf unseren Webseiten veröffentlicht und bei der Einladung zum Seminar verwendet.

Motivation

Technical debt is a metaphor used by software engineers to describe the challenges and trade-offs when evolving existing large bodies of code and system infrastructure. The metaphor refers to delayed tasks and immature artifacts that constitute a “debt” because they incur extra maintenance and evolution costs in the future. Incurring Technical Debt in a software development project is an expedient solution in the short term, yet this creates a context that increases complexity and costs in the long term. If managed well, some debt can accelerate design exploration and yield short-term market benefits. This metaphor is in essence an effective way of communicating design trade-offs and using software quality and business context data in a timely way to course correct. While other software engineering disciplines such as software sustainability, maintenance and evolution, refactoring, software quality, and empirical software engineering have produced results relevant to managing technical debt, none of them alone suffice to model, manage, and communicate the different facets of the design trade-off problem at hand. There is an urgency to combine these disciplines to better understand the problem of managing technical debt, as well as derive solutions that work in industrial practice. This urgency is motivated by several factors:

  • There is increasing recognition by industry that it is useful to articulate their most pressing software design and maintainability/evolvability challenges as technical debt. They are looking to research and pioneering organizations for available methods, tools, and guidance on possible immediate actions to take.
  • Existing research has identified and validated that the hardest problems related to technical debt tend to be architectural in nature, related to the structure and behavior of the system. While there is a vast body of research in code quality and analysis, this body of work needs to be better aligned to act as a foundation for understanding and managing architectural level concerns. Similarly, the existing body of work in software architecture design decision-making needs to be triaged for relevance to making progress in managing technical debt.
  • While several concepts and models have been put forward by researchers and tool vendors to help untangle the notion of technical debt, there is also ambiguity and misuse of terminology. We now have a good understanding of the core concepts in this metaphor, but at the same time there is an inflation of terms being proposed that may dilute the metaphor and weaken its usefulness.

During the seminar we will collectively develop:

  • a conceptual model to help frame the work in this area,
  • a reference process for managing technical debt in software organizations,
  • a framework for measurement and analysis of technical debt and
  • a roadmap for empirical research on this topic.

We plan to form working groups that can collaborate to expand on these four topics after the seminar, and propose ways to disseminate and share work done on technical debt.