=Paper=
{{Paper
|id=Vol-1771/paper15
|storemode=property
|title=Perspectives on Managing Technical Debt: A Transition Point and Roadmap from Dagstuhl
|pdfUrl=https://ceur-ws.org/Vol-1771/paper15.pdf
|volume=Vol-1771
|authors=Clemente Izurieta,Ipek Ozkaya,Carolyn Seaman,Philippe Kruchten,Robert Nord,Will Snipes,Paris Avgeriou
|dblpUrl=https://dblp.org/rec/conf/apsec/IzurietaOSKNSA16
}}
==Perspectives on Managing Technical Debt: A Transition Point and Roadmap from Dagstuhl==
https://ceur-ws.org/Vol-1771/paper15.pdf
1st International Workshop on Technical Debt Analytics (TDA 2016)
Perspectives on Managing Technical Debt
A Transition Point and Roadmap from Dagstuhl
Clemente Izurieta1, Ipek Ozkaya2, Carolyn Seaman3, Philippe Kruchten4, Robert Nord2, Will Snipes5, Paris Avgeriou6
1
clemente.izurieta@montana.edu, Montana State University, Bozeman, MT, USA
2
{ozkaya, rn}@sei.cmu.edu, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PA, USA
3
cseaman@umbc.edu, University of Maryland Baltimore County, Maryland, MD, USA
4
pbk@ece.ubc.ca, University of British Columbia, BC, Canada
5
will.snipes@us.abb.com, ABB Corporate Research, Raleigh, NC, USA
6
paris@cs.rug.nl, University of Groningen, Groningen, Netherlands
Abstract—Thirty-three practitioners, researchers, students, the periphery of the definition. Examples of the latter include
and tool vendors gathered in Dagstuhl, Germany, for five days in social, documentation, process, and infrastructure debt. We
April 2016 to discuss the state of managing technical debt in thus present a conceptual model that allows for extension and
software engineering. Participants reflected on the significant context representation of various artifacts.
advances that the Managing Technical Debt (MTD) community
has made since its inception in 2010; reached a consensus on a
definition, called the Dagstuhl 16K technical debt definition; and II. BACKGROUND
discussed avenues for future progress in the area. This paper The Management of Technical Debt (MTD) community
provides a brief history, summarizes current research, and offers has formally existed since 2010. Figure 1 depicts the timeline
a roadmap and a vision that describe the areas of research where of prior events and illustrates new meetings that represent an
significant challenges remain. increased level of activity. The outcome of these efforts has
been more than 200 research papers written by research
Keywords—technical debt; software quality; software decay; groups across the globe, systematic literature studies
software economics; software project management
organizing the space and demonstrating gaps, and special
issues in practitioner and research journals such as IEEE
I. INTRODUCTION Software and the Journal of Systems and Software. Possibly
While other software engineering disciplines—such as the most welcomed and challenging outcome has been an
software sustainability, maintenance and evolution, refactoring, ever-increasing involvement of the practitioner community.
software quality, and empirical software engineering—have As a result, many tool vendors have started adding or
produced results relevant to managing technical debt, none of repurposing features to support technical debt analysis. Many
them alone suffice to model, manage, and communicate the organizations are also looking into developing their own
different facets of the design trade-off problems involved in internal best practices for managing technical debt, and they
managing technical debt. Although the technical debt metaphor need help.
can be attributed to Cunningham [1], a community consensus Table 1 illustrates the topics on which technical debt
on a pithy and focused definition has been a barrier for research has focused since 2006. We clearly see a sharp
research progress that could address the most pressing distinction between artifacts that are easier to measure, such as
immediate needs of the software engineering community. The code, and those that are not, such as people. It also shows
technical debt metaphor describes a situation in which which topics have received more and less research.
developers accept quality compromises in the current release to
meet a deadline (e.g., delivering a release on time). A
subsequent release that has been compromised will incur a III. THE DAGSTUHL FORMAT
higher cost in the form of higher maintenance efforts. Dagstuhl brought together researchers, practitioners,
students, and tool vendors from academia and industry who are
To date, the technical debt metaphor has served as a strong
interested in the theoretical foundations of technical debt and
communication and reference mechanism, but the community
how to manage it (e.g., techniques for measurement, analysis,
now understands that technical debt is also a software
and prevention). The organizers created a blog where attendees
development artifact that is incurred (mostly) unintentionally
posted positions and started discussions to facilitate seeding of
and discovered during later stages of software development.
ideas prior to the seminar. Organizers grouped discussions and
Moreover, the community also recognizes that the key research
blog entries into relevant themes that included creating a
challenges ahead cannot be addressed by simply repurposing
common definition and conceptual model of technical debt,
code quality and maintainability analysis as technical debt
measurement and analysis of technical debt, management of
analytics. The Dagstuhl Seminar 16162 (Dagstuhl 16K)
technical debt, and a research roadmap for managing technical
definition of technical debt focuses on design and
debt. No long talks were featured. Each day had three types of
implementation artifacts that affect maintainability and
sessions. There was a plenary session for “lightning talks,” in
evolvability of software. This definition also prompted the
which each presenter had 10 minutes for presentation and
community to address the problem of classifying artifacts in
questions on each day except for the last day of the seminar.
84
1st International Workshop on Technical Debt Analytics (TDA 2016)
Fig. 1. Technical debt community events [3]
Table 1. Where is research focused? [4]
IV. TECHNICAL DEBT “In software-intensive systems, technical debt is a
The significant outcomes of the seminar include a collection of design or implementation constructs that are
definition, a conceptual model, and a list of challenges that we expedient in the short term, but set up a technical context that
face moving forward on the research agenda and transition can make future changes more costly or impossible. Technical
prospects for managing technical debt. The definition and debt presents an actual or contingent liability whose impact is
model serve as starting points for the community to build on limited to internal system qualities, primarily maintainability
and improve. and evolvability.”
The Dagstuhl 16K definition presents an expansion over B. Conceptual Model and Related Activities of Technical
past definitions by taking into account the concerns heard from Debt
prior technical debt events and the thinking that has occurred
Another outcome of the seminar was the recognition that,
over the years. Specifically, this definition elevates the
similar to other complex software engineering artifacts,
concepts of evolvability and maintainability as the primary foci
technical debt is best described through multiple viewpoints.
of technical debt research, combines design and
Concepts related to technical debt should be discussed based
implementation constructs, and highlights the context-specific
on two related viewpoints:
trade-offs that need to be made in an expedient manner.
a) the viewpoint describing the properties, artifacts, and
A. Definition of Technical Debt elements related to technical debt items (see Fig. 2)
Attendees converged on the following (Dagstuhl 16K) b) the viewpoint articulating the management- and
definition [2][5] for technical debt: process-related activities to perform or the different
states that debt may go through
85
1st International Workshop on Technical Debt Analytics (TDA 2016)
Fig. 2. Contextual figure of technical debt [2][5]
Figure 2 shows the conceptual model in the form of a UML go through. An activity-focused view would map out research
class diagram, which focuses on the first viewpoint and helped topics to be studied such as identifying, visualizing, assessing,
the group converge on key concepts. The technical debt and making decisions about technical debt. The phenomena all
associated with a software-intensive system is composed of a along the causal chain of causes and consequences are also
set of technical debt (TD) items, and this technical debt is one important to investigate.
of many concerns associated with a system. TD items have
both causes and consequences. The cause of technical debt can C. Technical Debt Management
be a process, a decision, an action (or lack thereof), or an event
Managing technical debt includes recognizing, analyzing,
that triggers the existence of that TD item, such as schedule
monitoring, and measuring it. Today many organizations do
pressure, unavailability of a key person, or lack of information
about a technical feature. The consequences of a TD item are not have established practices to manage technical debt, and
many: technical debt can affect the value of the system, the project managers and developers alike are asking for methods
costs of future changes, the schedule, and system quality. The and tools to help them strategically plan, track, and pay down
business objectives of the sponsoring organization developing technical debt. We identified two broad high-priority
or maintaining the software system are affected in several challenges:
ways: through delays, loss of quality for some features of the 1) Developing effective tooling (academia and industry) to
system, and difficulties in maintaining the system operations
assist with assessing technical debt: A number of studies have
(continuance). A TD item is associated with one or more
concrete, tangible artifacts of the software development examined the relationship between software code quality and
process, primarily the code, but also to some extent the technical debt. This work has applied detection of “code
documentation, known defects, and tests associated with the smells” (low internal code quality), coupling and cohesion,
system. and dependency analysis to identify technical debt. However,
empirical examples collected from industry all point out that
To keep with the financial metaphor, the cost impact of
technical debt can be seen as composed of principal and the most significant technical debt is caused by design trade-
interest. The principal is the cost savings gained by taking offs, which are not detectable by measuring code quality. For
some initial approach or shortcut in development (the initial example, an architectural decision encountered early in the
principal, often the initial benefit) or the cost that it would now design stage is the selection of a Visitor pattern vs.
take to develop a different or better solution (the current inheritance-based designs. Either design selection may be
principal). The interest is comprised of costs that add up as appropriate in the current context and would not yield smells;
time passes. There is recurring interest: additional cost however, later evolutionary steps may reveal different
incurred by the project in the presence of technical debt, due to maintenance problems, depending on the choice. Furthermore,
reduced velocity (or productivity), induced defects, and loss of several published case studies demonstrate that assessing
quality (maintainability is affected). And there is accruing
technical debt appropriately requires combining several
interest: the additional cost of developing new software
depending on not-quite-right code (evolvability is affected). analysis techniques together.
This view summarizing the elements related to technical 2) Establishing an empirical basis and data science for
debt, however, does not capture the activities that need to be technical debt: Well-defined benchmarks (with uncertainty
conducted to manage technical debt or the states that debt may levels) provide a basis for evaluating new approaches and
86
1st International Workshop on Technical Debt Analytics (TDA 2016)
ideas. They are also an essential first step toward creating an an essential relationship with how technical debt plays out in
empirical basis on which work in this area can grow more practice. Specific activities include
effectively. Effective and well-accepted benchmarks allow • identifying the important context factors (e.g., code
researchers to validate their work and tailor empirical studies volatility, business context, development personnel)
to be synergistic. Technical debt’s evolving definition and its that affect the evaluation of technical debt
sensitivity to context have inhibited the development of • understanding the relationship of other types of debt
benchmarks so far. An ideal benchmark for technical debt (e.g., social, infrastructure) as causes or consequences
research would consist of a code base, architectural models of technical debt
(perhaps with several versions), and known TD items. New • exploring the role of development methodologies to
approaches could be run against these artifacts to see how well manage technical debt
the approaches reveal TD items. Industry needs guidance for 3) The Necessary Infrastructure: Building the shared
how and what data to collect and what artifacts they can make infrastructure that facilitates all our research activities.
available to enable progress in understanding, measuring, and Specific activities include
managing technical debt. • sharing experimental data sets and study designs
V. RESEARCH ROADMAP AND VISION • creating benchmarks in an effort to standardize tools
and measures
The Dagstuhl participants spent some time envisioning
• developing techniques to inject different forms of
what the world would be like if technical debt research were
technical debt into data sets in order to evaluate,
as successful as we could ever hope it to be. The resulting
predict, and validate techniques
vision is summarized in the following points:
• Technical debt will be managed as well as we now CONCLUSION
manage defects, vulnerabilities, and new features.
Technical debt is an active field of research with a growing
• We have a way to translate developer concerns to
manager concerns—a basis for making decisions about community, as evidenced by the success of meetings and
allocating time for reducing technical debt. increased research output such as papers, commercial tools,
• Technical debt will be mostly incurred intentionally. and new projects. However, significant challenges remain to
• Projects that manage technical debt are more efficient, meet effective tooling demands, to establish an empirical
effective, and sustainable than projects that don’t. basis, and to pinpoint artifacts that serve as inputs to
• There is support for up-front and continuous measurement and analysis and most importantly to be useful
architectural work (vs. emergent architecture) and in practice. The research roadmap is an evolving document
evidence that it helps avoid and manage technical debt. and activity that requires active involvement from the greater
• Tools support all aspects of technical debt management, community of academics and practitioners alike. The hope is
and all stakeholders adopt them and use them. that it will continue to be refined and instantiated at gatherings
• Technical debt-aware development (practices and tools) of researchers and engineers interested in future research in
is an accepted way of producing software. technical debt management.
This vision set the stage for the beginnings of a research ACKNOWLEDGMENT
roadmap to guide future research to establish a cohesive body Copyright 2016 Carnegie Mellon University. This material is based upon
of knowledge about how to manage technical debt. The work funded and supported by the Department of Defense under Contract No.
FA8721-05-C-0003 with Carnegie Mellon University for the operation of the
research roadmap consists of three major parts: Software Engineering Institute, a federally funded research and development
center. NO WARRANTY. THIS CARNEGIE MELLON UNIVERSITY AND SOFTWARE
1) The Core: Defining, understanding, and ENGINEERING INSTITUTE MATERIAL IS FURNISHED ON AN “AS-IS” BASIS. CARNEGIE
operationalizing the concept of value with respect to technical MELLON UNIVERSITY MAKES NO WARRANTIES OF ANY KIND, EITHER EXPRESSED OR
IMPLIED, AS TO ANY MATTER INCLUDING, BUT NOT LIMITED TO, WARRANTY OF
debt. Specific activities include FITNESS FOR PURPOSE OR MERCHANTABILITY, EXCLUSIVITY, OR RESULTS OBTAINED
FROM USE OF THE MATERIAL. CARNEGIE MELLON UNIVERSITY DOES NOT MAKE ANY
• investigating the role of opportunity cost to measure WARRANTY OF ANY KIND WITH RESPECT TO FREEDOM FROM PATENT, TRADEMARK,
the differences in value between a decision to OR COPYRIGHT INFRINGEMENT. [Distribution Statement A] This material has
been approved for public release and unlimited distribution. Please see
implement new features that incur technical debt or
Copyright notice for non-US Government use and distribution. DM-0004135.
make infrastructure improvements that avoid technical We thank Tamara Marshall-Keim for her expert input.
debt while foregoing the features
• understanding the factors, beyond principal and REFERENCES
interest, that go into making decisions about incurring, [1] W. Cunningham, “The WyCash portfolio management system,”
paying off, and managing technical debt SIGPLAN OOPS Mess., Vol. 4, No. 2, pp. 29-30, Dec 1992.
[2] Managing Technical Debt in Software Engineering, Dagstuhl Reports,
• understanding how to model technical debt Vol. 6, Issue 4, April 17-22, 2016. http://www.dagstuhl.de/16162
phenomena over time, which is not linear in software [3] 8th International Workshop on Managing Technical Debt (MTD),
development Raleigh, NC, October 4, 2016.
[4] NSR Alves et al., Information and Software Technology 2016, Vol. 70,
2) The Essential Context: Understanding phenomena that pp. 100-121.
fall outside the core definition of technical debt and that have [5] Dagstuhl Blog. https://mtd2016dagstuhl
87