17. – 22. April 2016, Dagstuhl Seminar 16162
Managing Technical Debt in Software Engineering
Paris Avgeriou (University of Groningen, NL)
Philippe Kruchten (University of British Columbia – Vancouver, CA)
Ipek Ozkaya (Carnegie Mellon University – Pittsburgh, US)
Carolyn Seaman (University of Maryland, Baltimore County, US)
1 / 3 >
Auskunft zu diesem Dagstuhl Seminar erteilt
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?
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:
- the viewpoint describing the properties, artifacts, and elements related to technical debt items
- 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.
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.
Creative Commons BY 3.0 Unported license
Ipek Ozkaya and Philippe Kruchten and Robert Nord and Paris Avgeriou and Carolyn Seaman
- Software Engineering
- Technical debt
- Software quality
- Software evolution
- Software decay
- Software economics
- Software project management