Software engineers increasingly recognize technical debt as a problem they care about, but they lack methods and tools to help them strategically plan, track, and pay down debt. The concept provides a vocabulary to engage researchers from a practice point of view, but they often lack an empirical basis and data science on which to validate their work on technical debt. Our recent Dagstuhl Seminar on Managing Technical Debt in Software Engineering provided a venue for assessing how far the study of technical debt has come and envisioning where we need to go to further the science and practice of managing technical debt in the software life cycle.

The Journey from Metaphor to Theory and Practice

Six years ago 14 people attended a workshop at the Carnegie Mellon University Software Engineering Institute (SEI) to discuss research on managing technical debt in software-reliant systems. They recognized that the technical debt concept was gaining traction as a way to focus on the long-term management of accidental complexities created by short-term compromises during software development. The workshop participants formulated a research agenda statement that proposed that the software research community address the challenge of assessing the technical debt metaphor by developing validated theory and practices for the management of technical and economic tradeoffs with technical and executive decision makers as stakeholders.

Since that time, six more workshops have been held, with another to follow later this year (The Eighth International Workshop on Managing Technical Debt will be held in early October). Each workshop has attracted roughly 30 participants representing a cross section of research and industry and has resulted in around a dozen papers and presentations. These workshops have helped the participants make progress in research to move the concept of technical debt from a useful metaphor to a theoretical framework that enables reasoning about technical debt objectively. Highlights from the journey include the following:

• Surveying the software engineering landscape to scope the concept of technical debt: This landscape includes intentional technical debt (often related to architecture), technical debt due to a change in context (technological gap), and technical debt of a smaller granularity, mostly low internal code quality.

• Establishing the boundaries of the landscape with respect to evolution and maintenance: Defects, new features not yet implemented, and lack of process lie outside the boundary and are not technical debt. We distinguish system qualities visible to users from the invisible internal qualities or, rather, those visible only to software developers. Most defects and features have an immediate, current impact on the value of the product (positive or negative), whereas technical debt is felt in the future in the form of additional costs. Defects often are symptoms of technical debt.
• Understanding advanced concepts such as technical debt as part of an overall investment strategy: Intentional debt related to architecture can speed up time to market and allow an organization to put its code in the hands of its end users earlier, get feedback, and evolve it. The benefit is greater returns than a debt-free development process would reap if the software product is successful and the possibility of walking away from the debt if the software is not successful.
• Describing the concrete items of technical debt: A technical debt item is a single element of technical debt that connects a set of development artifacts. For example, in one case we know of, an organization incurred technical debt due to schedule pressure. The developers disregarded the scoping rules and made expedient implementation choices that resulted in close-coupling between two modules. When one of the modules was upgraded, the changes rippled to the other module and hit the project budget hard: 12KSLOC of additional, unplanned work that took months to complete.
  Technical debt becomes concrete as it relates to software units, in this case the two modules. Their coupling has consequences for the quality, value, and cost of the system. Once made visible, a technical debt item can be monitored and managed along with other change requests in the backlog of project issues.
• Arriving at the crossroad where a number of research paths are converging: Research from several domains is maturing to become part of the answer to the technical debt question of how we quantify and monitor the economic impact of decisions over time. This maturation includes software engineering disciplines in software aging and decay, risk management, qualitative methods and appreciation for context, software metrics, program analysis, and software quality.

A Working Definition and Core Concepts of Technical Debt

We organized a week-long Dagstuhl Seminar on Managing Technical Debt in Software Engineering earlier this year to refine the working definition and core concepts of technical debt. The examples we see of technical debt and tool support today focus mostly on structural quality that eventually impacts maintainability, evolvability, and the runtime behavior of the system. Given this perspective, attendees settled on the following working definition:

In software-intensive systems, technical debt is the 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 that impacts internal system qualities, primarily maintainability and evolvability.

There is ongoing discussion on what differentiates technical debt from other software anomalies. As we acquire better understanding of behavioral quality in addition to structural quality, we will better understand the impact of technical debt on system qualities of all types.

The following conceptual model served as the starting point for the discussion of core concepts that are important to make progress on quantification of technical debt. The motivation behind refining a common model is accelerating progress towards objective analysis that can lead to standards for better software development practices and tool support.

Technical debt (highlighted words refer to elements in the conceptual model) is one of the many concerns associated with a software-intensive system. The technical debt associated with a system is composed of technical debt items. Technical debt items have causes and consequences. The causes of technical debt can be an action (or lack of action) that triggers the existence of that debt item, such as a decision, schedule pressure, lack of process, unavailability of a key person, lack of information about a technical feature, and so on.

The consequences of a technical debt item are many: it affects the cost and value of the system, directly or by negatively impacting the schedule or quality of the system. The business goals of the sponsoring organization developing or maintaining the software system are affected in several ways: through schedule delay, loss of quality in some system features, or difficulties in the continuance of system operations. Symptoms are a subset of the consequences that are directly observable or measurable.

A technical debt item is associated with one or more concrete, tangible artifacts of the software development process. These include primarily code, but also architecture, deployment/delivery infrastructure such as build scripts and test suites, and to a certain extent the documentation and known defects associated with the system.

A conceptual model like this one is a step forward in understanding quantification, what artifacts to look at, and what techniques are needed to analyze the consequences of debt. In a previous blog post, we provided a list of properties to describe a technical debt item based on these concepts.

Tasks Ahead

As the size of software grows, technical debt does too. Its management is becoming the dominant driver of software engineering progress. Sustaining our pace of innovation while ensuring software quality therefore involves establishing technical-debt management as a core software engineering practice.

The organizers of the Dagstuhl Seminar advocated that researchers, practitioners, tool developers, and educators work together toward the following vision:

Vision for Managing Technical Debt

The convergence of efforts on these multiple fronts is necessary to make software development technically and economically sustainable. Otherwise, the friction that slows down the machinery of software evolution will threaten the discipline's ability to maintain the code base on which society depends.

Wrapping Up

The topic of technical debt is crossing the chasm from early pioneers to mainstream software engineering venues. For example, work on technical debt is appearing in research tracks at top software engineering conferences. Moreover, special issues have been devoted to technical debt and studies of studies have extracted core concepts on the topic. Work on technical debt is moving beyond the definition to characterizing impact: By defining benchmarks, reaching out to other communities, and adjusting the roadmap, we have still have much to learn about technical debt along our journey from metaphor to practice.

The work reported in this study is part of a wider SEI effort on technical debt. If you would like to collaborate on a study of managing technical debt, please get in touch. We welcome your feedback on our definition and conceptual model of technical debt and the challenges you face in the comments section below.

Resources

This post is a summary of the ideas presented by the organizers of the Managing Technical Debt (MTD) Workshop Series: Paris Avgeriou (University of Groningen), Philippe Kruchten (University of British Columbia), Robert L. Nord (Software Engineering Institute), Ipek Ozkaya (Software Engineering Institute), Carolyn Seaman (University of Maryland Baltimore County), and the many participants of the workshops. You can learn more from the following resources.

Avgeriou, P., Kruchten, P., Nord, R., Ozkaya, I., and Seaman, C. 2016. Reducing Friction in Software Development. IEEE Software 33, 1 (2016), 66−73.

Brown et al. Managing Technical Debt in Software-Reliant Systems, Workshop on the Future of Software Engineering Research, Foundations of Software Engineering, 2010.

Dagstuhl Seminar on Managing Technical Debt in Software Engineering, 2016.

Managing Technical Debt Workshop Series.