Technical Debt is considered the “silent killer” of software projects. In a recent survey, software developers claimed they spend 13.5 hours weekly on Technical Debt, one-third of their working time1. The industry now has widespread consensus that managing Technical Debt should be treated as a core software engineering practice. Companies are increasingly incorporating Technical Debt management practices into their development processes [2], [6]. Many software quality tools now incorporate features to help software engineering teams visualize and triage quality issues within their code bases to assist Technical Debt management.

This advancement in industrial practice is paired with very vibrant research. The research community has produced a substantial body of knowledge on the topic of Technical Debt, especially in investigating the problem and its manifestation, understanding its urgency and impact, and proposing solutions to address it. This research is often performed in collaboration with industry, indicating its practical relevance but also the aligned interests of researchers and practitioners. The maturity of research in Technical Debt is evidenced by the increasing number of publications and systematic literature reviews since the first research paper was published in 2010 [1]. A recent tertiary study reviewing secondary studies in managing technical debt reported 532 unique research studies [3].

Despite the significant progress made in industry practices, commercial tools, and the research on the body of knowledge on Technical Debt Management, there are five critical gaps.

Lack of tools. While there is widespread use of static analysis tools to detect code quality issues, not all of them indicate Technical Debt, and there is significant confusion around their use. For example, several commonly used industry tools report different results for simple measures such as size, complexity, file cycles, and package cycles [4]. In addition, the software engineering community is unclear on what a Technical Debt management tool is.

Difficulty in understanding the impact of AI on Technical Debt. There is tremendous momentum around developing software with AI-based tools whose implications on new forms of Technical Debt are unclear. Consequently, while the industry is driving the simplification of code generation with AI-augmented tools to develop vast new quantities of code and develop it fast, it also risks incurring large volumes of unanticipated Technical Debt. Furthermore, the reality of industrial software engineering is dealing with a significant amount of legacy software. In these heritage systems, accumulated Technical Debt exists, but teams often lack resources to address the underlying issues. A large portion of that Technical Debt was introduced many years prior; it remains hidden and undocumented and involves design or architecture issues that cannot be mined by analyzing source code.

Lack of theory on Technical Debt economics. The bottom line of Technical Debt management is the Return On Investment (ROI) for the business and value, as difficult as it is to quantify the financial bottom line reliably. Existing research, while aimed to address complicated concepts such as the principal and interest of Technical Debt, fails to recognize that a new software economics approach is needed to concretely capture the cost of ownership and value aspects of Technical Debt.

Not focusing on architecture. Industry challenges consistently emphasize the difficulties around managing architecture-level Technical Debt where the tradeoffs are more implicit and complex. However, we observe the proverbial “lamp post” research, as researchers tend to focus on the easy part (code) rather than the more valuable but also more challenging part (architecture).

Narrow scope and data. There is not sufficient emphasis on the social side of Technical Debt Management. This is reflected in the limited research datasets: they only contain code artifacts and are not validated with human subjects. In addition, data sets that allow understanding of the socio-technical aspects of Technical Debt are lacking.

This Dagstuhl Perspectives Workshop brought together researchers, tool vendors, and software practitioners to analyze these gaps and reframe the field of technical debt, focusing on the following key challenge areas and guiding research questions:

• Technical Debt as value-creation: How can the value of Technical Debt be managed in an informed and conscious manner to meet business goals while still avoiding prohibitively high-interest payments in the future?
• Elevating the role of architecture: How can software architecture considerations be integrated into Technical Debt Management to elevate it beyond code-level issues?
• Next-generation tooling: How can new and existing tools better focus on Technical Debt Management, including taking advantage of AI-based capabilities where appropriate?
• New perspectives on data collection: How can forms of data beyond code analysis, such as architecture, documentation artifacts, and business artifacts, inform Technical Debt Management?
• Socio-technical aspects: Given that Technical Debt is often a matter of how individuals and teams operate, how can social aspects be integrated into Technical Debt Management?

Workshop Format

Before the workshop, a key reading list was distributed to the attendees to familiarize them with the most recent advances in Technical Debt Management. The workshop itself featured four elements:

• Plenary Sessions which included sharing organizational details, lightning talks on the five key challenges by all participants, reporting from the break-out groups, brainstorming on the vision, and planning ahead.
• Break-out Sessions which included brainstorming, discussions, and write-up sessions of the state of the art, as well as the values, beliefs, and principles of the manifesto, and finally, the roadmap towards realizing the manifesto. Each session had five break-out groups that corresponded to the aforementioned five key challenge areas.
• Open Spaces which allowed participants to propose and subsequently discuss additional related topics in a group setting.
• Interactive and Inclusive Sessions following some of the Liberating Structures. These included activities such as “Impromptu Networking” to mine important challenges, a “User Experience Fishbowl” to share successes and concerns in both industry and research, a “Chaos Cocktail Party” to prioritize intermediate results, and a game to strengthen team bonding.

The participants in this workshop were carefully selected to obtain a balanced representation of the three main stakeholder groups in software engineering: (1) researchers whose work focuses on Technical Debt, (2) practitioners regularly dealing with Technical Debt, and (3) ntool vendors who develop tools to address different aspects of Technical Debt Management. A list of participants is provided at the end of the final report.

During the workshop, the lightning talks allowed the participants to get to know each other's backgrounds, work, and goals. The break-out sessions made up the majority of the workshop agenda and were the most intense sessions, producing hundreds of post-it notes, which were grouped into themes and subsequently transcribed to inform the resulting manifesto document. Each day, the break-out groups were slightly re-shuffled, with one or two new members joining each group to offer a fresh point of view. The outcomes of each break-out group were peer-reviewed by another group to offer feedback from a different perspective.

Various Open Spaces were proposed by workshop participants that covered a number of topics that complemented the five workshop topics: one open space dealt with "green" Technical Debt focusing on sustainability, another with different facets of Technical Debt (e.g., people, processes, business), and a third discussed how to create purpose-built Technical Debt benchmarks in a way they can be commonly accepted. The interactive sessions using the Liberating Structures were effective in energizing the participants after lunch and allowing a more engaging format to lead the discussions. As the workshop progressed, it became clear that the participants understood each other's perspectives better and became more efficient in their brainstorming and in-depth discussions.

Identifying Technical Debt Challenges

Following the lightning talks, the workshop agenda included an impromptu networking session. This activity aimed to provide participants an opportunity to interact with each other through an engaging activity and to elicit the challenges that the group collectively perceived as important.

Participants were asked to answer the following question on small cards: What is the top priority challenge the Technical Debt community should make progress on to improve its management by software development teams? The Technical Debt community here refers to researchers, tool vendors, and practitioners who are actively working on Technical Debt and its management. The participants then passed around their cards to read as many answers as possible. There were three impromptu pauses during this reading session, where the participants paired up and rated the challenge statements. This activity at the end of three rounds resulted in all cards having a rating by three different pairs. The top ten challenges the participants elicited are the following (in decreasing rating):

• Integrating tooling into existing development ecosystems in a non- or less-disruptive fashion
• Providing practical guidance to software development teams about when to accept Technical Debt
• Expressing the importance of Technical Debt to users, leaders, funding groups
• Helping C-level executives understand the strategic value of proper Technical Debt Management
• Developing techniques to prioritize technical debt so that the issues with the highest ROI can be addressed first to support efficiency, motivate developers/management to actually address Technical Debt, and avoid waste.
• Convincing business stakeholders to invest in Technical Debt repayment (not all Technical Debt has to be repaid) or not, including explaining the benefits in terms of money, but also risk management
• Extracting the context that underpins a team’s Technical Debt, such as process, Technical Debt culture, and domain
• Easily determining the impact of Technical Debt reduction measures (e.g., regarding productivity gains, cost reduction, compliance mistakes) to support decision-making for product owners
• Developing tools that capture a commonly agreed Technical Debt viewpoint aligned with the company culture
• Transitioning from low-level code issues to architecture-level technical debt (architecture is defined as “expensive to change”)

Industry/Academia Perspectives Session

A user experience “fishbowl” session on the first day highlighted several key insights about measuring and managing Technical Debt, capturing the different perspectives in industry and academia. While metrics were deemed often incomplete, subjective, or difficult to act upon, participants noted that the context around Technical Debt, for example, expressed in source code comments (also known as self-admitted debt [5]) could be utilized more in the future. Measuring Technical Debt and creating feedback loops can provide valuable data at varying levels, from developers to C-level executives. However, blindly optimizing specific metrics can lead to unintended consequences, such as wasted effort or undue pressure on teams. Empirical research today tends to focus heavily on source code analysis, missing the broader development and system context, which makes capturing a holistic view of Technical Debt challenging.

To improve Technical Debt Management, industry participants recommended appointing a “Technical Debt champion” within software development teams/organizations to educate and advocate for best practices, especially towards management. They also suggested adapting research methods from other disciplines, such as social sciences, creating more purpose-built Technical Debt Management tools that seamlessly integrate into developer and decision-maker workflows, and demonstrating how Technical Debt impacts innovation to secure buy-in from upper management. These approaches aim to create more actionable strategies for addressing Technical Debt while maintaining alignment with organizational goals. The fishbowl session was thus instrumental in eliciting some of the participant’s core values, beliefs, and principles regarding Technical Debt, which is at the heart of the manifesto.

Open Space on the Multi-Dimensionality of Technical Debt

Technical Debt emerges from decisions or other phenomena (e.g., deprecation of a library) throughout the software development cycle, jeopardizing software maintenance and evolution and affecting most development workflows. However, managing Technical Debt takes significant effort and time. One of the main reasons is that different context variables and factors (peopleware, processes, products, business, etc.) influence how Technical Debt is managed or even perceived. It certainly goes far beyond source code, and there is no single metric that can accurately capture the concept. This Open Space discussed ways to measure Technical Debt, taking those multiple perspectives into account, as well as evidence-based metrics required to support decision-making.

The participants agreed that collecting both objective and subjective data is necessary, as well as a way to aggregate these two types. This aggregation should take stakeholders' concerns into account (what stakeholders want to know to make decisions). Quantitative measures can be contextualized by qualitative ones. The combination of measures must represent the context and match the organization; context is key.

Representation of Technical Debt also requires multiple metrics; a single number is hard to understand and interpret and may hide or obscure the complexities underlying Technical Debt. In addition, graphical representations are useful but must be followed by an explanation (recommendation) to provide value to stakeholders (CEO, Project Owner, developers, and so on).

Beyond metrics, Technical Debt items must include other contextual information. How exactly does it hinder development? Why was it incurred in the first place? This kind of context should drive data collection. Sometimes, specific Technical Debt items need different metrics and contextual information as they affect development differently.

There is still much tacit knowledge involved in managing technical debt, especially in identifying, measuring, prioritizing, and repaying it. Therefore, experienced software developers have a relevant role in mentoring their more junior colleagues in understanding the software structure and behavior, as well as past design decisions. Traceability between software artifacts (e.g., between source code and documentation) can facilitate making this tacit knowledge explicit. However, in general, software professionals must be prepared to spend time understanding the context behind technical debt items.

Based on the aforementioned issues, the Open Space participants identified several research directions:

• How to identify meaningful objective metrics that should be automatically collected?
• How to measure and manage developer “turnover” (e.g., the departure of developers with knowledge of legacy code)?
• How to capture current developers’ perspectives about Technical Debt?
• How to record the design decisions that incur Technical Debt?
• How to aggregate different unit metrics?
• What is the interplay between Indicators of Technical Debt and Metrics of Technical Debt?

• How to incorporate a human-in-the-loop within the Technical Debt management process?

• How to adequately capture the balance between Technical Debt repayment and the development of new features, especially regarding quality, risks, and costs?

Manifesto

The core outcome of this workshop is a report published in the Dagstuhl Manifestos series, titled Reframing Technical Debt. This manifesto report summarizes the current landscape of Technical Debt methods and tools and explains where current industrial practice is struggling, where current research has made progress, and where it falls short. This motivates the actual manifesto, which condenses the outcomes of the workshop into a series of values, beliefs, and principles.

The manifesto reports subsequently explains the stated values, beliefs, and principles in detail. Finally, it outlines a roadmap with concrete milestones and a call to action addressed at researchers, software practitioners, tool vendors, Technical Debt advocates, policymakers and other government agencies, leading technology companies, funding agencies, industry leaders, and industry associations. The manifesto is signed by the workshop participants.

Concept Map

During the lightning talks and plenary discussions, the organizers captured key concepts discussed and how they related to each other as a concept map. This concept map (Figure 1), though not exhaustive, offers a perspective on the multidisciplinary nature of Technical Debt, its management, and its essential role in software engineering.

The rest of this report includes abstracts from workshop attendees summarizing their relevant work, which informed the discussions during the workshop.

References

1. Nanette Brown, Yuanfang Cai, Yuepu Guo, Rick Kazman, Miryung Kim, Philippe Kruchten, Erin Lim, Alan MacCormack, Robert Nord, Ipek Ozkaya, Raghvinder Sangwan, Carolyn Seaman, Kevin Sullivan, and Nico Zazworka. Managing technical debt in software-reliant systems. In Proceedings of the FSE/SDP Workshop on Future of Software Engineering Research, FoSER ’10, page 47–52, New York, NY, USA, 2010. Association for Computing Machinery.
2. Ciera Jaspan and Collin Green. Defining, measuring, and managing technical debt. IEEE Softw., 40(3):15–19, May 2023.
3. Helvio Jeronimo Junior and Guilherme Horta Travassos. Consolidating a common perspective on technical debt and its management through a tertiary study. Information and Software Technology, 149:106964, 2022.
4. Jason Lefever, Yuanfang Cai, Humberto Cervantes, Rick Kazman, and Hongzhou Fang. On the lack of consensus among technical debt detection tools. In 2021 IEEE/ACM 43rd International Conference on Software Engineering: Software Engineering in Practice (ICSE-SEIP), pages 121–130, 2021.
5. Aniket Potdar and Emad Shihab. An exploratory study on self-admitted technical debt. In 2014 IEEE International Conference on Software Maintenance and Evolution, pages 91–100. IEEE, 2014.
6. Wolfgang Trumler and Frances Paulisch. How “specification by example” and test-driven development help to avoid technial debt. In 2016 IEEE 8th International Workshop on Managing Technical Debt (MTD), pages 1–8, 2016.

Creative Commons BY 4.0

Paris Avgeriou, Ipek Ozkaya, Heiko Koziolek, Zadia Codabux, and Neil Ernst