TOP
Search the Dagstuhl Website
Looking for information on the websites of the individual seminars? - Then please:
Not found what you are looking for? - Some of our services have separate websites, each with its own search option. Please check the following list:
Schloss Dagstuhl - LZI - Logo
Schloss Dagstuhl Services
Seminars
Within this website:
External resources:
  • DOOR (for registering your stay at Dagstuhl)
  • DOSA (for proposing future Dagstuhl Seminars or Dagstuhl Perspectives Workshops)
Publishing
Within this website:
External resources:
dblp
Within this website:
External resources:
  • the dblp Computer Science Bibliography


Please select your role
to obtain appropriate quick-links.
As a LIPIcs/OASIcs author, you will be invited by e-mail to register at the Dagstuhl Submission Server. The server will guide you through the publication workflow. Preliminary information can be found here:
Quick Links

Dagstuhl Seminar 16162

Managing Technical Debt in Software Engineering

( Apr 17 – Apr 22, 2016 )
(Click in the middle of the image to enlarge)
Permalink
Please use the following short url to reference this page: https://www.dagstuhl.de/16162
Organizers
Contact
Publications
Impacts
Motivation
Show 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.

Summary
Show Summary

The term technical debt refers to delayed tasks and immature artifacts that constitute a "debt" because they incur extra costs in the future in the form of increased cost of change during evolution and maintenance. The technical debt metaphor provides an effective mechanism for communicating design trade-offs between developers and other decision makers. When managed effectively, technical debt provides a way to gauge the current maintainability of a system and correct the course when that level is undesirable. 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 problems involved in managing technical debt.

Despite recent progress by the research community in understanding technical debt, increased attention by tool vendors on assessing technical debt through code conformance checking, and collaboration with industry in sharing data and challenges, there are several open questions about the role of technical debt in software development. The goal of this seminar was to establish a common understanding of key concepts of technical debt and build a road map for future work in this area to address these open questions.

How do we define and model technical debt? The software engineering community is converging on defining technical debt as making technical compromises that are expedient in the short term, but that create a technical context that increases complexity and cost in the long term. While the conceptual roots of technical debt imply an idealized, deliberate decision-making process and rework strategy as needed, we now understand that technical debt is often incurred unintentionally and catches software developers by surprise. Hence, it is mostly observed during maintenance and evolution. Technical debt as a metaphor serves as a strong communication mechanism, but the community now understands that technical debt is also a software development artifact. This overloaded nature creates confusion, especially for newcomers to the field. In addition, there is a risk of associating anything detrimental to software systems and development processes with technical debt. This risk necessitates crisply defining both technical debt and related concepts.

How do we manage technical debt? Well-defined benchmarks provide a basis for evaluating new approaches and ideas. They are also an essential first step toward creating an empirical basis on which work in this area can grow more effectively. Effective and well-accepted benchmarks allow researchers to validate their work and tailor empirical studies to be synergistic. Technical debt’s evolving definition and its sensitivity to context have inhibited the development of benchmarks so far. An ideal benchmark for technical debt research would consist of a code base, architectural models (perhaps with several versions), and known technical-debt items (TD items). New approaches to identify technical debt could be run against these artifacts to see how well the approaches reveal TD items. Industry needs guidance for how and what data to collect and what artifacts they can make available to enable progress in understanding, measuring, and managing technical debt.

How do we establish an empirical basis and data science for technical debt?

Seminar Format

In this seminar, we brought together researchers, practitioners, and tool vendors from academia and industry who are interested in the theoretical foundations of technical debt and how to manage it from measurement and analysis to prevention. Before the seminar, the organizers created a blog where attendees could post positions and start discussions to facilitate seeding of ideas.

Before the seminar, the organizers grouped discussions and blog entries into relevant themes that included creating a common definition and conceptual model of technical debt, measurement and analysis of technical debt, management of technical debt, and a research road map for managing technical debt.

Our goal was to make this seminar a working week; hence we had a dynamic schedule. We did not feature any long talks. Each day had three types of sessions. There was a plenary session for "lightning talks," in which each presenter had 10 minutes for presentation and questions on each day except for the last day of the seminar. The second type of session was for breakout discussions. Breakout sessions focused on themes that emerged from the blog and the goals of the seminar. Participants first discussed these in randomly assigned small groups in order to maximize cross-pollination of ideas. Last, we had plenary discussion sessions to collate and summarize the discussions during the breakouts. At the end of each day, the organizers asked for feedback and adjusted the flow of the following day accordingly. As a result, we dedicated the fourth day of the seminar to an "un-conference"' format in which the discussion topic emerged based on the interests and votes of the attendees. The summaries of these sessions are included in Section 5: Open Problems.

The Definition of Technical Debt and a Conceptual Model

At the conclusion of the seminar, attendees agreed on the following working definition of technical debt, which we refer to as the 16162 definition of technical debt:

In software-intensive systems, technical debt is a collection of design or implementation constructs that are expedient in the short term, but set up a technical context that can make future changes more costly or impossible. Technical debt presents an actual or contingent liability whose impact is limited to internal system qualities, primarily maintainability and evolvability.

A significant outcome of the week was the recognition that, similar to other complex software engineering artifacts, technical debt is best described through multiple viewpoints. Concepts related to technical debt in particular should be discussed based on two related viewpoints:

  1. the viewpoint describing the properties, artifacts, and elements related to technical debt items
  2. the viewpoint articulating the management- and process-related activities to perform, or the different states that debt may go through

Figure 1 shows the initial conceptual model that served as the starting point for discussions. This model helped the group converge on key concepts. Mismatches occurred when the discussions focused on causes that may or may not be input to measurement and analysis. The dynamic view is intended to articulate these aspects.

The technical debt associated with a software-intensive system is composed of a set of TD items, and this technical debt is one of many concerns associated with a system. TD items have both causes and consequences. The cause of technical debt can be a process, a decision, an action (or lack thereof), or an event that triggers the existence of that TD item, such as schedule pressure, unavailability of a key person, or lack of information about a technical feature.

The consequences of a TD item are many: technical debt can effect the value of the system, the costs of future changes, the schedule, and system quality. The business objectives of the sponsoring organization developing or maintaining the software system are affected in several ways: through delays, loss of quality for some features of the system, and difficulties in maintaining the system operations (continuance).

A TD item is associated with one or more concrete, tangible artifacts of the software development process, primarily the code, but also to some extent the documentation, known defects, and tests associated with the system.

To keep with the financial metaphor, the cost impact of technical debt can be seen as composed of principal and interest. The principal is the cost savings gained by taking some initial approach or shortcut in development (the initial principal, often the initial benefit) or the cost that it would now take to develop a different or better solution (the current principal).

The interest is comprised of costs that add up as time passes. There is recurring interest: additional cost incurred by the project in the presence of technical debt, due to reduced velocity (or productivity), induced defects, and loss of quality (maintainability is affected). And there are accruing interests: the additional cost of the developing new software depending on not-quite-right code (evolvability is affected).

This view summarizing the elements related to technical debt, however, does not capture causes that may or may not be input to measurement and analysis, the activities that need to be conducted to manage technical debt, and the states debt may go through. Another view is intended to articulate these aspects.

This definition and the model serve as the starting point for the community to build on and improve.

Research Road Map

One outcome of the seminar was a broad agenda for future work in technical debt research. While this road map needs to be fleshed out in the future with more detailed research questions and problem statements, it lays out three areas that require attention. First is the identification of a core concept -- value -- that is central to the technical debt metaphor and that needs definition and operationalization. Second is a recognition that there is an important context to technical debt that should be studied. There are attributes of the context of any particular instance of technical debt in a real environment that must be understood. But there are also other phenomena that are related to technical debt that should be studied, such as other types of "debt." Third, the road map lays out the community's basic infrastructure needs, which will enable further collaboration and progress in this area. The research road map that arose out of the discussions at Dagstuhl is described in more detail in this report under Sectio 4: Working Groups.

Follow-up Work

At the seminar, participants recognized that a carefully considered conceptual model and research road map would be useful outputs for the broader community interested in managing technical debt. Hence, more comprehensive explanation of a conceptual model and the research road map are planned as publications in appropriate venues once the community has a chance to vet the ideas further. The blog established before the seminar will continue to facilitate this interaction.

Copyright Ipek Ozkaya and Philippe Kruchten and Robert Nord and Paris Avgeriou and Carolyn Seaman
Participants
Show Participants
  • Areti Ampatzoglou (University of Groningen, NL) [dblp]
  • Francesca Arcelli Fontana (University of Milano-Bicocca, IT) [dblp]
  • Rami Bahsoon (University of Birmingham, GB) [dblp]
  • Ayse Basar Bener (Ryerson University - Toronto, CA) [dblp]
  • Frank Buschmann (Siemens AG - München, DE) [dblp]
  • Alexandros Chatzigeorgiou (University of Macedonia - Thessaloniki, GR) [dblp]
  • Zadia Codabux (Mississippi State University, US) [dblp]
  • Bill Curtis (CAST - Fort Worth, US) [dblp]
  • Steven D. Fraser (HP Inc. - Palo Alto, US) [dblp]
  • Alfredo Goldman (University of Sao Paulo, BR) [dblp]
  • Christine Hofmeister (East Stroudsburg University, US) [dblp]
  • Johannes Holvitie (University of Turku, FI) [dblp]
  • Clemente Izurieta (Montana State University - Bozeman, US) [dblp]
  • Andreas Jedlitschka (Fraunhofer IESE - Kaiserslautern, DE) [dblp]
  • Sven Johann (innoQ GmbH - Monheim am Rhein, DE) [dblp]
  • Heiko Koziolek (ABB AG Forschungszentrum - Ladenburg, DE) [dblp]
  • Philippe Kruchten (University of British Columbia - Vancouver, CA) [dblp]
  • Jean-Louis Letouzey (inspearit - Paris, FR) [dblp]
  • Antonio Martini (Chalmers UT - Göteborg, SE) [dblp]
  • John D. McGregor (Clemson University, US) [dblp]
  • Mehdi Mirakhorli (Rochester Institute of Technology, US) [dblp]
  • J. David Morgenthaler (Google Inc. - Mountain View, US) [dblp]
  • Robert Nord (Carnegie Mellon University - Pittsburgh, US) [dblp]
  • Ipek Ozkaya (Carnegie Mellon University - Pittsburgh, US) [dblp]
  • Fabio Queda Bueno da Silva (Federal University of Pernambuco - Recife, BR) [dblp]
  • Klaus Schmid (Universität Hildesheim, DE) [dblp]
  • Carolyn Seaman (University of Maryland, Baltimore County, US) [dblp]
  • Andriy Shapochka (SoftServe - Lviv, UA) [dblp]
  • Forrest Shull (Carnegie Mellon University - Pittsburgh, US) [dblp]
  • Will Snipes (ABB - Raleigh, US) [dblp]
  • Damian Andrew Tamburri (Polytechnic University of Milan, IT) [dblp]
  • Graziela Tonin (University of Sao Paulo, BR) [dblp]
  • Guilherme Horta Travassos (UFRJ / COPPE, BR) [dblp]
Related Seminars
  • Dagstuhl Perspectives Workshop 24452: Reframing Technical Debt (2024-11-03 - 2024-11-08) (Details)
Classification
  • software engineering
Keywords
  • Technical debt
  • Software quality
  • Software evolution
  • Software decay
  • Software economics
  • Software project management
Seminar 16162
© 2024 Schloss Dagstuhl – Leibniz-Zentrum für Informatik GmbH
ImprintContactAccessibilityPrivacy