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