Background: Effective management of Technical Debt (TD) is essential for improving software quality and sustainability. However, there is a lack of evidence about the benefits of TD management practices.

Abstract In Agile software development, maintaining velocity requires the continuous management of Technical Debt (TD). However, the rapid iteration cycles inherent to Agile often obscure debt accumulation, making manual identification in issue trackers prohibitively expensive. To address this, we present TD-Suite, a comprehensive framework engineered to automate the classification of technical debt. It leverages state-of-the-art transformer models to analyze textual artifacts, such as developer discussions in issue reports, where subtle indicators of debt often lie hidden. TD-Suite provides a seamless end-to-end pipeline suitable for Agile ML Engineering, managing everything from initial data ingestion and rigorous preprocessing to model training, thorough evaluation, and final inference. It supports both binary classification (debt or no debt) and granular categorization—identifying code, architecture, design, or documentation debt—enabling Agile teams to formulate targeted refactoring strategies. To ensure robustness on real-world, imbalanced datasets, TD-Suite incorporates k-fold cross-validation, early stopping, and class weighting strategies. The framework explicitly integrates the tracking and reporting of carbon emissions associated with model training. Furthermore, it features a user-friendly Gradio web interface within a Docker container, simplifying integration into DevOps pipelines and democratizing access for practitioners without deep ML expertise.

Abstract Managing software quality is crucial for maintainable software systems, yet understanding how quality attributes are discussed within the informal, noisy context of issue trackers remains a significant challenge. Current automatic approaches for categorizing quality concerns often falter, as they are typically validated on small domain-specific datasets and are ill-equipped to parse the conversational language of developer discourse. This hinders effective prioritization and technical debt management. This paper introduces QualiTagger, an automated approach for classifying seven distinct software quality attributes from issue tracker text, and QualiDataSet, a novel, curated dataset of over 700,000 labeled GitHub issues that underpins this work. We demonstrate that an ensemble of specialized binary classifiers, built upon the DistilRoBERTa architecture, significantly outperforms a single multiclass model and shows superior or comparable efficacy to a general-purpose Large Language Model (GPT-4o) for this task. The model’s real-world applicability is further validated through an industrial case study at Visma focusing on security issues) and a user study with software engineering students. Our evaluation confirms that QualiTagger achieves high classification accuracy and, crucially, generalizes effectively to previously unseen (Out-of-Distribution) projects, a key indicator of its practical utility. By providing both a robust classification tool and a large-scale public dataset, this research enables a more nuanced, data-driven understanding of how software quality is managed in practice, offering valuable insights for project management and future empirical software engineering research

Machine learning (ML) codebases face unprecedented challenges in maintaining code quality and sustainability as their complexity grows exponentially. While traditional code smell detection tools exist, they fail to address ML-specific issues that can significantly impact model performance, reproducibility, and maintainability. This paper introduces MLScent, a novel static analysis tool that leverages sophisticated Abstract Syntax Tree (AST) analysis to detect anti-patterns and code smells specific to ML projects. MLScent implements 76 distinct detectors across major ML frameworks including TensorFlow (13 detectors), PyTorch (12 detectors), Scikit-learn (9 detectors), and Hugging Face (10 detectors), along with data science libraries like Pandas and NumPy (8 detectors each). The tool's architecture also integrates general ML smell detection (16 detectors), and specialized analysis for data preprocessing and model training workflows. Our evaluation demonstrates MLScent's effectiveness through both quantitative classification metrics and qualitative assessment via user studies feedback with ML practitioners. Results show high accuracy in identifying framework-specific anti-patterns, data handling issues, and general ML code smells across real-world projects.

Technical Debt (TD) is a critical challenge in software development, leading to increased maintenance costs and reduced software quality over time. While considerable research has focused on identifying and managing TD in Java projects, studies on. NET (C#) projects remain limited. Additionally, existing approaches often rely on a single tool for TD detection, overlooking the benefits of combining multiple tools. In this paper, we analyze the effectiveness of Arcan, CodeScene, Designite, and DV8 on four industrial C#. NET 8 software products to address these research gaps. To validate and enrich our findings, we conducted online seminars and interviews with developers, architects, and managers involved in these projects, gathering practitioner insights on TD relevance and tool effectiveness. By leveraging complementary tools and practitioner feedback, we uncover different types of TD, including code-level, design, architectural, and knowledge debt. Our findings highlight each tool's strengths and limitations and demonstrate how integrating their outputs with expert input provides a more comprehensive and actionable TD assessment. Based on these insights, we propose a conceptual model for prioritizing and managing TD, offering guidance for practitioners.

The growth of Python adoption across diverse domains has led to increasingly complex codebases, presenting challenges in maintaining code quality. While numerous tools attempt to address these challenges, they often fall short in providing comprehensive analysis capabilities or fail to consider Pythonspecific contexts. PyExamine addresses these critical limitations through an approach to code smell detection that operates across multiple levels of analysis. PyExamine architecture enables detailed examination of code quality through three distinct but interconnected layers: architectural patterns, structural relationships, and code-level implementations. This approach allows for the detection and analysis of 49 distinct metrics, providing developers with an understanding of their codebase’s health. The metrics span across all levels of code organization, from high-level architectural concerns to granular implementation details. Through evaluation on 7 diverse projects, PyExamine achieved detection accuracy rates: $91.4 \%$ for code-level smells, $89.3 \%$ for structural smells, and $80.6 \%$ for architectural smells. These results were further validated through extensive user feedback and expert evaluations, confirming PyExamine’s capability to identify potential issues across all levels of code organization with high recall accuracy. In additional to this, we have also used PyExamine to analysis the prevalence of different type of smells, across 183 diverse Python projects ranging from small utilities to large-scale enterprise applications. PyExamine’s distinctive combination of comprehensive analysis, Python-specific detection, and high customizability makes it a valuable asset for both individual developers and large teams seeking to enhance their code quality practices.

While Technical Debt (TD) manifest in systems as code-related symptoms, it is often caused by management-related issues. However, existing TD visualization tools are primarily code-based, and limited in addressing organizational factors. In this context, we introduce DebtQuest: an interactive, survey-based visualization tool designed to help assess an organization’s TD management practices. DebtQuest enables stakeholders to explore insights, pinpoint issues, perform benchmarking, and compare changes across time. Complementing the capabilities of code-based tools to discover TD symptoms, DebtQuest supports the discovery of underlying organizational causes. DebtQuest’s design is grounded in task analysis and a targeted review of relevant visualization techniques. It was refined through real-world use and evaluated by industry stakeholders. The contribution of this work is an accessible and flexible visualization design that extends recent research in TD management, revealing organizational insights that are difficult to discover using code-based tools.

Abstract Visualization is a promising technique in TD management, but with various tools offering visualization, the question arise: is it being used effectively by practitioners? Through an analysis of survey data from 417 participants across seven international companies, we examine the current use of visualization and its perceived potential to improve TD management. Our findings reveal that while visualization tools are not widely used, there is a clear desire for enhanced visualization capabilities.

Technical Debt (TD) identification in software projects issues is crucial for maintaining code quality, reducing long-term maintenance costs, and improving overall project health. This study advances TD identification in issues tracker using transformer-based models, addressing the critical need for accurate and efficient TD identification in large-scale software development. Our methodology employs multiple binary classifiers for TD and its type, combined through ensemble learning , to enhance accuracy and robustness in detecting various forms of TD. We train and evaluate these models on a comprehensive dataset from GitHub Archive Issues (2015–2024), supplemented with industrial data validation. We demonstrate that in-project fine-tuned transformer models significantly outperform task-specific fine-tuned models in TD classification, highlighting the importance of project-specific context in accurate TD identification. Our research also reveals the superiority of specialized binary classifiers over multi-class models for TD and its type identification, enabling more targeted debt resolution strategies. A comparative analysis shows that the smaller DistilRoBERTa model is more effective than larger language models like GPTs for TD classification tasks , especially after fine-tuning, offering insights into efficient model selection for specific TD detection tasks. The study also assesses generalization capabilities using metrics such as MCC, AUC ROC, Recall, and F1 score, focusing on model effectiveness, fine-tuning impact, and relative performance . By validating our approach on out-of-distribution and real-world industrial datasets, we ensure practical applicability, addressing the diverse nature of software projects. This research significantly enhances TD detection and offers a more nuanced understanding of TD types, contributing to improved software maintenance strategies in both academic and industrial settings. The release of our curated dataset aims to stimulate further advancements in TD classification research , ultimately enhancing software project outcomes and development practices by enabling early TD identification and management.

ABSTRACT Process debt, like technical debt, can be a source of short‐term benefits but often leads to harmful consequences in the long term for a software organization. Despite its impact, the phenomenon of process debt has not been thoroughly explored in current literature, leaving a gap in understanding how it affects and is managed within organizations. This paper addresses this gap by defining process debt, describing its occurrence, the risks of its mismanagement, and showing examples of mitigation strategies. Our study began with an exploratory phase involving semi‐structured interviews with sixteen practitioners across four international organizations, allowing us to gather diverse insights into the occurrence and management of process debt. Then, to deepen our understanding and validate our findings, we conducted a cross‐company focus group with ten additional practitioners and analyzed fifty‐eight observations and thirty‐five interviews from a longitudinal case study. The analysis of the research findings led to a definition of process debt and a novel framework. We also report on the causes, consequences, and occurrence patterns of process debt over time. We present mitigation strategies and discuss which ones need further attention for future research. Our results suggest that the debt metaphor may help companies understand how to manage and improve their processes and make process‐related decisions that are beneficial both in the short and long term.

ABSTRACT Modern software development faces a critical bottleneck in manually prioritizing the overwhelming volume of issues generated in platforms like Jira and GitHub. This labor‐intensive process leads to delays, increased costs, inconsistent handling, and developer burnout, worsened by the lack of standardized priority labels. This paper investigates the potential of automated issue priority classification using state‐of‐the‐art Transformer models to alleviate this burden. We evaluate the performance of models like BERT, DeBERTa, and ModernBERT, comparing them against general large language models (LLMs) such as GPT‐3.5, Qwen2.5‐3B and Llama‐3.2‐3B, using curated datasets derived from public Jira and GitHub repositories. Our research addresses the effectiveness of these models for their generalization capabilities on out‐of‐distribution projects, the impact of fine‐tuning, and performs a detailed performance comparison across different priority levels and model types. Results demonstrate that Transformer models, particularly ModernBERT, achieve high classification performance (e.g., accuracy > 81%), significantly outperforming the evaluated general LLMs (accuracy 75%) for this specific task. We find that binary classification is more effective than multilabel approaches, models generalize well to unseen projects, and performance is further enhanced by fine‐tuning. Key contributions include the provision of cleaned, labeled datasets and a comprehensive evaluation confirming the viability and benefits of using specialized Transformer models for automated issue priority suggestion, offering a path to improved efficiency and resource allocation in software development workflows.

Background: Technical Debt (TD) needs to be controlled and tracked during software development. Support to automatically track TD in issue trackers is limited. Aim: We explore the usage of a large dataset of developer-labeled TD issues in combination with cutting-edge Natural Language Processing (NLP) approaches to automatically classify TD in issue trackers. Method: We mine and analyze more than 160GB of textual data from GitHub projects, collecting over 55,600 TD issues and consolidating them into a large dataset (GTD dataset). We use such datasets to train and test Transformer ML models. Then we test the model’s generalization ability by testing them on six unseen projects. Finally, we re-train the models including part of the TD issues from the target project to test their adaptability. Results and conclusion: (i) We create and release the GTD dataset, a comprehensive dataset including TD issues from 6,401 public repositories with various contexts; (ii) By training Transformers using the GTD dataset, we achieve performance metrics that are promising; (iii) Our results are a significant step forward towards supporting the automatic classification of TD in issue trackers, especially when the models are adapted to the context of unseen projects after fine-tuning.

Background: As Machine Learning (ML) advances rapidly in many fields, it is being adopted by academics and businesses alike. However, ML has a number of different challenges in terms of maintenance not found in traditional software projects. Identifying what causes these maintainability challenges can help mitigate them early and continue delivering value in the long run without degrading ML performance. Aim: This study aims to identify and synthesise the maintainability challenges in different stages of the ML workflow and understand how these stages are interdependent and impact each other’s maintainability. Method: Using a systematic literature review, we screened more than 13000 papers, then selected and qualitatively analysed 56 of them. Results: (i) a catalogue of maintainability challenges in different stages of Data Engineering, Model Engineering workflows and the current challenges when building ML systems are discussed; (ii) a map of 13 maintainability challenges to different interdependent stages of ML that impact the overall workflow; (iii) Provided insights to developers of ML tools and researchers. Conclusions: In this study, practitioners and organisations will learn about maintainability challenges and their impact at different stages of ML workflow. This will enable them to avoid pitfalls and help to build a maintainable ML system. The implications and challenges will also serve as a basis for future research to strengthen our understanding of the ML system’s maintainability.

When developing software, it is vitally important to keep the level of technical debt down since, based on several studies, it has been well established that technical debt can lower the development productivity, decrease the developers' morale and compromise the overall quality of the software, among others. However, even if researchers and practitioners working in today's software development industry are quite familiar with the concept of technical debt and its related negative consequences, there has been no empirical research focusing specifically on how software managers actively communicate and manage the need to keep the level of technical debt as low as possible. This study aims to understand how software companies give incentives to manage technical debt. This is carried out by exploring how companies encourage and reward practitioners for actively keeping the level of technical debt down add whether the companies use any forcing or penalising initiatives when managing technical debt. As a first step, this paper reports the results of both an online survey providing quantitative data from 258 participants and interviews with 32 software practitioners. As a second step, this study sets out to specifically provide a detailed assessment of additional and in-depth analysis of technical debt management strategies based on an encouraging mindset and attitude from both managers and technical roles to understand how, when and by whom such strategies are adopted in practice. Our findings show that having a technical debt management strategy (specially based on encouragement) can significantly impact the amount of technical debt related to the software. The result indicates that there is considerable unfulfilled potential to influence how software practitioners can further limit and reduce technical debt by adopting a strategy based explicitly on an encouraging mindset from managers where they also specifically dedicate time and resources for technical debt remediation activities.

Background: Technical Debt is a consolidated notion in software engineering research and practice. However, the estimation of its impact (interest of the debt) is still imprecise and requires heavy empirical and experimental inquiry. Objective: We aim at developing a data-driven approach to calculate the interest of Technical Debt in terms of delays in resolving affected tasks.Method: We conducted a case study to estimate the Technical Debt interest by analyzing its association with the lead time variation of resolving related Jira issues.Results: Data-driven approaches could significantly change the Technical Debt estimation and improve the removing Technical Debt prioritization. Our case study shows that the presence of Code Technical Debt did not affect the lead time for resolving the issues.Conclusion: Future works include the further refinement of this approach and its application to a larger data-set and on different type of issues.

Based on multiple series of interviews and workshops, this paper presents the MaLET model – a representation of the typical evolution path for companies who successfully adopt exploratory testing. The model provides a step-by-step approach to systematically improve exploratory testing over time, and shows how and why capabilities may regress. The MaLET model was validated through a series of interviews with 20 interviewees from eight case study companies in separate industry segments. The interviews also revealed examples on improvement initiatives that had failed in the companies, showing that improvement initiatives tend to fail if they are not planned in an order corresponding to the maturity levels in the model. The MaLET model was well received by the interviewees during the validation, describing the model as sound, relevant and useful in practice.

Architectural technical debt (ATD) may create a substantial extra effort in software development, which is called interest. There is little evidence about whether repaying ATD in microservices reduces such interest. Objectives: We wanted to conduct a first study on investigating the effect of removing ATD on the occurrence of incidents in a microservices architecture. Method: We conducted a quantitative and qualitative case study of a project with approximately 1000 microservices in a large, international financing services company. We measured and compared the number of software incidents of different categories before and after repaying ATD. Results: The total number of incidents was reduced by 84%, and the numbers of critical- and high-priority incidents were both reduced by approximately 90% after the architectural refactoring. The number of incidents in the architecture with the ATD was mainly constant over time, but we observed a slight increase of low priority incidents related to inaccessibility and the environment in the architecture without the ATD. Conclusion: This study shows evidence that refactoring ATDs, such as lack of communication standards, poor management of dead-letter queues, and the use of inadequate technologies in microservices, reduces the number of critical- and high-priority incidents and, thus, part of its interest, although some low priority incidents may increase.

Abstract Context Software engineering is a human activity. Despite this, human aspects are under-represented in technical debt research, perhaps because they are challenging to evaluate. Objective This study’s objective was to investigate the relationship between technical debt and affective states (feelings, emotions, and moods) from software practitioners. Method Forty participants ( N = 40) from twelve companies took part in a mixed-methods approach, consisting of a repeated-measures ( r = 5) experiment ( n = 200), a survey, and semi-structured interviews. From the qualitative data, it is clear that technical debt activates a substantial portion of the emotional spectrum and is psychologically taxing. Further, the practitioners’ reactions to technical debt appear to fall in different levels of maturity. Results The statistical analysis shows that different design smells (strong indicators of technical debt) negatively or positively impact affective states. Conclusions We argue that human aspects in technical debt are important factors to consider, as they may result in, e.g., procrastination, apprehension, and burnout.

Eliciting scalability requirements during agile software development is complicated and poorly described in previous research. This article presents a lightweight artifact for eliciting scalability requirements during agile software development: the ScrumScale model. The ScrumScale model is a simple spreadsheet. The scalability concepts underlying the ScrumScale model are clarified in this design science research, which also utilizes coordination theory. This paper describes the open banking case study, in which a legacy banking system becomes open. This challenges the scalability of this legacy system. The first step in understanding this challenge is to elicit the new scalability requirements. In the open banking case study, key stakeholders from TietoEVRY spent 55 h eliciting the scalability requirements of TietoEVRY’s open banking project. According to TietoEVRY, the ScrumScale model provided a systematic way of producing scalability requirements. For TietoEVRY, the scalability concepts behind the ScrumScale model also offered significant advantages in dialogs with other stakeholders.

Software companies need to manage and refactor Technical Debt issues. Therefore, it is necessary to understand if and when refactoring of Technical Debt should be prioritized with respect to developing features or fixing bugs. The goal of this study is to investigate the existing body of knowledge in software engineering to understand what Technical Debt prioritization approaches have been proposed in research and industry. We conducted a Systematic Literature Review of 557 unique papers published until 2020, following a consolidated methodology applied in software engineering. We included 44 primary studies. Different approaches have been proposed for Technical Debt prioritization, all having different goals and proposing optimization regarding different criteria. The proposed measures capture only a small part of the plethora of factors used to prioritize Technical Debt qualitatively in practice. We present an impact map of such factors. However, there is a lack of empirical and validated set of tools. We observed that Technical Debt prioritization research is preliminary and there is no consensus on what the important factors are and how to measure them. Consequently, we cannot consider current research conclusive. In this paper, we therefore outline different directions for necessary future investigations.

Using a microservices architecture is a popular strategy for software organizations to deliver value to their customers fast and continuously. However, scientific knowledge on how to manage architectural debt in microservices is scarce. In the context of microservices applications, this paper aims to identify architectural technical debts (ATDs), their costs, and their most common solutions. We conducted an exploratory multiple case study by conducting 25 interviews with practitioners working with microservices in seven large companies. We found 16 ATD issues, their negative impact (interest), and common solutions to repay each debt together with the related costs (principal). Two examples of critical ATD issues found were the use of shared databases that, if not properly planned, leads to potential breaks on services every time the database schema changes and bad API designs, which leads to coupling among teams. We identified ATDs occurring in different domains and stages of development and created a map of the relationships among those debts. The findings may guide organizations in developing microservices systems that better manage and avoid architectural debts.

Process Debt, like Technical Debt, can be the source of short-term benefits but often is harmful in the long term for a software organization. Nonetheless, information about Process Debt is scarce in current literature. We conducted an exploratory study of Process Debt in four international organizations by interviewing 16 practitioners. The findings show that Process Debt can be a harmful phenomenon that needs attention and new practices, as it is different from Technical Debt. We provide an initial framework, composed by a definition and a conceptual model for Process Debt, showing types, causes, consequences, and debt accumulation patterns.

When developing software, it is vitally important to keep the level of technical debt down since it is well established from several studies that technical debt can, e.g., lower the development productivity, decrease the developers' morale, and compromise the overall quality of the software. However, even if researchers and practitioners working in today's software development industry are quite familiar with the concept of technical debt and its related negative consequences, there has been no empirical research focusing specifically on how software managers actively communicate and manage the need to keep the level of technical debt as low as possible.

As the development progresses, software projects tend to accumulate Technical Debt and become harder to maintain. Multiple tools exist with the mission to help practitioners to better manage Technical Debt. Despite this progress, there is a lack of tools providing actionable and self-learned suggestions to practitioners aimed at mitigating the impact of Technical Debt in real projects. We aim to create a data-driven, lightweight, and self-learning tool positioning highly impactful refactoring proposals on a Jira backlog. Bearing this goal in mind, the first two authors have founded a startup, called Skuld.ai, with the vision of becoming the go-to software renovation company. In this tool paper, we present the software architecture and demonstrate the main functionalities of our tool. It has been showcased to practitioners, receiving positive feedback. Currently, its release to the market is underway thanks to an industry-research institute collaboration with Fraunhofer IESE to incorporate self-learning technical debt capabilities.

In recent years in the software industry, the use of safety-critical software is increasing at a rapid rate. However, little is known about the relationship between safety-critical regulations and the management of technical debt. The research is based on interviews with 19 practitioners working in different safety-critical domains implementing software according to different safety regulation standards. The results are three-fold. First, the result shows that performing technical debt refactoring tasks in safety-critical software requires several additional activities and costs, compared to non-safety-critical software. This study has also identified several negative effects due to the impact of these regulatory requirements. Second, the results show that the safety-critical regulations strengthen the implementation of both source code and architecture and thereby initially limit the introduction of technical debt. However, at the same time, the regulations also force the software companies to perform later suboptimal work-around solutions that are counterproductive in achieving a high-quality software since the regulations constrain the possibility of performing optimal TD refactoring activities. Third, the result shows that technical debt refactoring decisions are heavily weighed on the costs associated with the application's recertification process and that these decisions seldom include the benefits of the refactoring activities in a structured way.

This paper identifies three improvement areas related to system design and architecture, where an organization can change to better support continuous integration and continuous delivery: “The product's architecture”, “Ways to work with system design and architecture”, and “The role of the architect”. The three improvement areas are based on a literature review, two series of interviews and a cross-company workshop with three case-study companies. Furthermore, the paper proposes three actionable strategies corresponding to the three identified improvement areas: “Systems with a modular and loosely coupled architecture”, “A balanced approach where system design and architecture is focused on the system's most important characteristics”, and “Architects shifting perspective from control to facilitation”.

Remediation of technical debt through regular refactoring initiatives is considered vital for the software system's long and healthy life. However, since today's software companies face increasing pressure to deliver customer value continuously, the balance between spending developer time, effort, and resources on implementing new features or spending it on refactoring of technical debt becomes vital. The goal of this study is to explore how the prioritization of technical debt is carried out by practitioners within today's software industry. This study also investigates what factors influence the prioritization process and its related challenges. This paper reports the results of surveying 17 software practitioners, together with follow-up interviews with them. Our results show that there is no uniform way of prioritizing technical debt and that it is commonly done reactively without applying any explicit strategies. Often, technical debt issues are managed and prioritized in a shadow backlog, separate from the official sprint backlog. This study was also able to identify several different challenges related to prioritizing technical debt, such as the lack of quantitative information about the technical debt items and that the refactoring of technical debt issues competes with the implementation of customer requirements.

Architectural technical debt can be generated by changes in the business and the environment of an organization. In this paper, we emphasize the change in scalability requirements due to new regulations. Scalability is the ability of a system to handle an increased workload. For complex systems that are abruptly exposed via open interfaces and hence a greater workload, the scalability requirements may quickly increase, leading to technical debt. We term this scalability debt. This paper describes scalability triage, a light-weight, novel technique for identifying scalability threats as a form of technical debt. We illustrate this technique with an open banking case from a large software organization. Open banking is partly caused by the new European PSD2 regulative that enforce banks to open interfaces to unknown third-party actors. Banking systems are well-established, mature systems. However, with the advent of open banking and PSD2, the workload may quickly rocket. This leads to tougher scalability requirements and accumulated architectural debt, despite previously sound architectural decisions. Using scalability triage, such risks may be identified fast. It will then be possible to prevent this form of technical debt with timely reengineering.

Introduction: Software companies aim to achieve continuous delivery to constantly provide value to their customers. A popular strategy is to use microservices architecture. However, such an architecture is also subject to debt, which hinders the continuous delivery process and thus negatively affects the software released to the customers. Objectives: The aim of this study is to identify issues, solutions and risks related to Architecture Technical Debt in microservices. Method: We conducted an exploratory case study of a real life project with about 1000 services in a large, international company. Through qualitative analysis of documents and interviews, we investigated Architecture Technical Debt in the communication layer of a system with microservices architecture. Results: Our main contributions are a list of Architecture Technical Debt issues specific for the communication layer in a system with microservices architecture, as well as their associated negative impact (interest), a solution to repay the debt and the its cost (principal). Among the found Architecture Technical Debt issues were the existence of business logic in the communication layer and a high amount of point-to-point connections between services. The studied solution consists of the implementation of different canonical models specific to different domains, the removal of business logic from the communication layer, and migration from services to use the communication layer correctly. We also contributed with a list of possible risks that can affect the payment of the debt, as lack of funding and inadequate prioritization. Conclusion: We found issues, solutions and possible risks that are specific for microservices architectures not yet encountered in the current literature. Our results may be useful for practitioners that want to avoid or repay Technical Debt in their microservices architecture.

Software companies need to continuously deliver customer value, both from a short- and long-term perspective. However, software development can be impeded by what has been described as Technical Debt (TD). The aim of this study is to explore the negative consequences of TD in terms of wasted software development time. This study also investigates on which additional activities this wasted time is spent and whether different types of TD impact the wasted time differently. This study also sets out to examine the benefits of tracking and communicating the amount of wasted time, both from a developer's and manager's perspective. This paper reports the results of a longitudinal study, surveying 43 software developers, together with follow-up interviews with 16 industrial software practitioners. The analysis of the reported wasted time revealed that developers waste, on average, 23% of their development time due to TD and that they are frequently forced to introduce new TD due to already existing TD. The most common activity on which additional time is spent is performing additional testing.

It is challenging to assess and manage Technical Debt. Technical Debt is avoided or refactored if the long-term benefits, such as preventing extra-costs, exceed the cost of repaying the debt.

Software startups are typically under extreme pressure to get to market quickly with limited resources and high uncertainty. This pressure and uncertainty is likely to cause startups to accumulate technical debt as they make decisions that are more focused on the short-term than the long-term health of the codebase. However, most research on technical debt has been focused on more mature software teams, who may have less pressure and, therefore, reason about technical debt very differently than software startups. In this study, we seek to understand the organizational factors that lead to and the benefits and challenges associated with the intentional accumulation of technical debt in software startups. We interviewed 16 professionals involved in seven different software startups. We find that the startup phase, the experience of the developers, software knowledge of the founders, and level of employee growth are some of the organizational factors that influence the intentional accumulation of technical debt. In addition, we find the software startups are typically driven to achieve a "good enough level," and this guides the amount of technical debt that they intentionally accumulate to balance the benefits of speed to market and reduced resources with the challenges of later addressing technical debt.

Large software companies need to support continuous and fast delivery of customer value both in the short and long term. However, this can be hindered if both the evolution and maintenance of existing systems are hampered by Technical Debt. Although a lot of theoretical work on Technical Debt has been produced recently, its practical management lacks empirical studies. In this paper, we investigate the state of practice in several companies to understand what the cost of managing TD is, what tools are used to track TD, and how a tracking process is introduced in practice. We combined two phases: a survey involving 226 respondents from 15 organizations and an in-depth multiple case study in three organizations including 13 interviews and 79 Technical Debt issues. We selected the organizations where Technical Debt was better tracked in order to distill best practices. We found that the development time dedicated to managing Technical Debt is substantial (an average of 25% of the overall development), but mostly not systematic: only a few participants (26%) use a tool, and only 7.2% methodically track Technical Debt. We found that the most used and effective tools are currently backlogs and static analyzers. By studying the approaches in the companies participating in the case study, we report how companies start tracking Technical Debt and what the initial benefits and challenges are. Finally, we propose a Strategic Adoption Model for the introduction of tracking Technical Debt in software organizations.

Background: In the last two decades Technical Debt (TD) has received a considerable amount of attention from software engineering research and practice. Recently, a small group of studies suggests that, in addition to its technical and economic consequences, TD can affect developers' psychological states and morale. However, until now there has been a lack of empirical research clarifying such influences. Aims: In this study, we aim at taking the first step in filling this gap by investigating the potential impacts of TD and its management on developers' morale. Method: Drawing from previous literature on morale, we decided to explore the influence of TD and its management on three dimensions of morale called affective, future/goal, and interpersonal antecedents. In so doing, we conducted an exploratory field study and collected data from software professionals active in different industrial domains through eight qualitative interviews and an online survey (n=33). Results: Our results indicate that TD mainly has a negative influence on future/goal and affective antecedents of morale. This is mainly because the occurrence of TD hinders developers from performing their tasks and achieving their goals. TD management, on the other hand, has a positive influence on all the three dimensions of morale since it is associated with positive feelings and interpersonal feedback as well as a sense of progress. Conclusions: According to the results of this empirical study, the occurrence of TD reduces developers' morale, while its management increases developers' morale.

The negative consequences of Technical Debt is an area of increasing interest, and more specifically the Architectural aspects of it have received increased attention in the last few years. Besides the negative effects of Architectural Technical Debt on the overall software product quality in terms of hindering evolution and causing high maintenance costs, Architectural Technical Debt also has a significant negative impact on software practitioners' daily work. Although a great deal of theoretical work on Architectural Technical Debt has been undertaken, there is a lack of empirical studies that examine the negative effects of Architectural Technical Debt during the software development lifecycle. The aim of this study is to investigate how practitioners perceive and estimate the impact of Architectural Technical Debt during the software development process. This paper reports the results of an online web survey providing quantitative data from 258 participants. The contribution of this paper is threefold: First, it shows that practitioners experience that the Architectural type of Technical Debt has the highest negative impact on daily software development work. Secondly, we provide evidence that does not support the commonly held belief that Architectural Technical Debt increases with the age of the software. Thirdly, we show that despite different responsibilities and working tasks of software professionals, Architectural Technical Debt negatively affects all roles without any significant difference between the roles.

Software companies need to support continuous and fast delivery of customer value both in short and a long-term perspective. However, this can be hindered by evolution limitations and high maintenance efforts due to internal software quality issues by what is described as Technical Debt. Although significant theoretical work has been undertaken to describe the negative effects of Technical Debt, these studies tend to have a weak empirical basis and often lack quantitative data. The aim of this study is to estimate wasted time, caused by the Technical Debt interest during the software life-cycle. This study also investigates how practitioners perceive and estimate the impact of the negative consequences due to Technical Debt during the software development process. This paper reports the results of both an online web-survey provided quantitative data from 258 participants and follow-up interviews with 32 industrial software practitioners. The importance and originality of this study contributes and provides novel insights into the research on Technical Debt by quantifying the perceived interest and the negative effects it has on the software development life-cycle. The findings show that on average, 36% of all development time is estimated to be wasted due to Technical Debt; Complex Architectural Design and Requirement Technical Debt generates most negative effect; and that most time is wasted on understanding and/or measuring the Technical Debt. Moreover, the analysis of the professional roles and the age of the software system in the survey revealed that different roles are affected differently and that the consequences of Technical Debt are also influenced by the age of the software system.

Abstract A known problem in large software companies is to balance the prioritization of short‐term and long‐term business goals. As an example, architecture suboptimality (Architectural Technical Debt), incurred to deliver fast, might hinder future feature development. However, some technical debt generates more interest to be paid than other. We conducted a multi‐phase, multiple‐case embedded case study comprehending 9 sites at 6 large international software companies. We have investigated which architectural technical debt items generate more interest , how the interest occurs during software development and which costly extra‐activities are triggered as a result. We presented a taxonomy of the most dangerous items identified during the qualitative investigation and a model of their effects that can be used for prioritization, for further investigation and as a quality model for extracting more precise and context‐specific metrics. We found that some architectural technical debt items are contagious, causing the interest to be not only fixed, but potentially compound, which leads to the hidden growth of interest (possibly exponential). We found important factors to be monitored to refactor the debt before it becomes too costly. Instances of these phenomena need to be identified and stopped before the development reaches a crises.

Large software companies need to support continuous and fast delivery of customer value both in the short and long term. However, this can be hindered if both evolution and maintenance of existing systems are hampered by Technical Debt. Although a lot of theoretical work on Technical Debt has been recently produced, its practical management lacks empirical studies. In this paper we investigate the state of practice in several companies in order to understand how they start tracking Technical Debt. We combined different methodologies: we conducted a survey, involving 226 respondents from 15 organizations and a more in-depth multiple case-study in three organizations, where Technical Debt was tracked: we involved 13 interviews and 79 Technical Debt issues analysis. We found that the development time dedicated to manage Technical Debt is substantial (around 25% of the overall development) but not systematic: only a few participants methodically track Technical Debt. By studying the approaches in the companies participating in the case-study, we understood how companies start tracking Technical Debt and what are the initial benefits and challenges. Finally, we propose a Strategic Adoption Model based to define and adopt a dedicated process for tracking Technical Debt.

Fast software deliveries are hindered by high maintenance efforts due to internal quality issues and Technical Debt (TD) and specifically, Architectural Technical Debt (ATD) has received increased attention in the last few years. ATD has a significant influence and impact on system success and, left unchecked, it can cause expensive repercussions, it is, therefore, of maintenance and evolutionary importance to understand the basic underlying factors of ATD. Thus, with this as background, there is a need for a descriptive model to illustrate and explain the different ATD issues. The aim of this study is to synthesize and compile research efforts with the goal of creating new knowledge with a specific interest in the ATD field. The contribution of this paper is the presentation of a novel descriptive model, providing a comprehensive interpretation of the ATD phenomenon. This model categorizes the main characteristics of ATD and reveals their corresponding relations. The model is based on a systematic literature review (SLR) of currently recognized knowledge concerning ATD.

In recent years, research and industry's attention has been focused on maintaining a system that would both decrease time to market in the short term and assure a sustainable feature output and smooth maintenance operations in the long run. A related phenomenon has been identified in Architectural Technical Debt: if the system architecture is sub-optimal for long-term business goals, it needs to be refactored. A key property of the system assuring long-term goals consists on modularity, or else the ability to decouple different components: such property allows the product to be evolved without costly changes pervading the whole system. However, understanding the business benefits of refactoring to achieve modularity is not trivial, especially for large refactorings involving substantial architectural changes. We have conducted a case study in a large company, analyzing a case of refactoring a component to achieve modularity. We report a comparative study of a refactored against a non-refactored component. We found that the modularization would be repaid in several months of development and maintenance. We present a method to calculate the effort saved by the modularization and an equation for calculating and quantifying the development and maintenance benefits of refactoring.

In order to continuously support the value delivery both in short-term and long-term, a key goal for large software companies is to continuously develop and manage software architecture. In order to understand how architecture management is employed in large Agile software companies, we have conducted interviews involving several roles at 5 firms. Through a combination of structured inductive and deductive analysis proper of Grounded Theory, we have identified current architect roles and gaps in the architecture practices in the studied organizations. From such investigation, we have developed an organizational framework, CAFFEA, for Agile architecting, including roles, (virtual) teams and practices. The framework has been evaluated through a cross-company workshop including participants from 5 large software companies, discussion groups and a final survey. Finally, we have evaluated the framework in practice after one year of its application at one of the companies. We found that some necessary architectural practices are overlooked in Large Agile Software Development. The evaluation of CAFFEA framework showed that the included roles and teams are needed in order to mitigate the gaps in the architectural practices. The responsibilities and the activities have been mapped to key architect roles compatible with the Scrum setting employed at the companies. The evaluation of CAFFEA shows key benefits.

The adoption of Agile Software Development in large companies is a recent phenomenon of great interest both for researchers and practitioners. Although intra-team interaction is well supported by established agile practices, the critical interaction between the agile team and other parts of the organization is still unexplored in literature. Such interactions slow down the development, hindering the achievement of business goals based on speed: short time to market, quick replication of products of a product-line, and reaction time for product evolution. We have employed a two-year long multiple-case case-study, collecting data through interviews and a survey in three large companies developing embedded software. Through a combination of qualitative and quantitative analysis, we have found strong evidence that interaction challenges between the development team and other groups in the organization hinder speed and are widespread in the organizations. This paper also identifies current practices in use at the studied companies and provides detailed guidelines for novel solutions in the investigated domain. Such practices are called boundary-spanning activities in information system research and coordination theory. We present a comparison between large embedded software companies employing agile and developing a line of products based on reused assets and agile companies developing pure software. We highlight specific contextual factors and areas where novel spanning activities are needed for mitigating the interaction challenges hindering speed. Copyright © 2015 John Wiley & Sons, Ltd.

A known problem in large software companies is to balance the prioritization of short-term with long-term viability. Specifically, architecture violations (Architecture Technical Debt) taken to deliver fast might hinder future feature development. However, some technical debt requires more interest to be paid than other. We have investigated which Technical Debt items generate more effort and how this effort is manifested during software development. We conducted a multiple-case embedded case study comprehending 7 sites at 5 large international software companies. We found that some Technical Debt items are contagious, causing other parts of the system to be contaminated with the same problem, which may lead to non-linear growth of interest. We also identify another socio-technical phenomenon, for which a combination of weak awareness of debt, time pressure and refactoring creates Vicious Circles of events during the development. Such phenomena need to be identified and stopped before the development is led to a crisis point. Finally, this paper presents a taxonomy of the most dangerous items identified during the qualitative investigation and a model of their effects that can be used for prioritization, for further investigation and as a quality model for extracting more precise and context-specific metrics.

An open issue in industry is the combination of software reuse in the context of large scale Agile Software Development. The speed offered by Agile Software Development is needed for short time to market, while reuse strategies such as Software Product Line Engineering are needed for long-term productivity, efficiency, and profit. The paper investigates, through a survey, communication factors affecting both speed and reuse in 3 large companies developing embedded systems and employing Agile Software Development and Software Product Line Engineering. Our results include a prioritized list of communication related factors obtained by statistical analysis and the recognition and spread of the factors in the companies. We have recognized 5 interfaces with the Agile development team that need to be improved: system engineers (architects), product management, distributed teams, inter-project teams and sales unit. Few factors (involving inter-project communication) depend on the business drivers for the company. We also reveal that Agile teams need strategic and architectural inputs in order to be implanted in a large company employing Software Product Line Engineering. Academic and industrial training as well as different tactics for co-location would improve the communication skills of engineers. There is also a need for solutions, in the reference architecture, for fostering Agile Software Development: the goal is the combination of the focus on customer value of the teams, reusability, system requirements and avoidance of organizational dependencies.

An open issue in industry is software reuse in the context of large scale Agile product development. The speed offered by agile practices is needed to hit the market, while reuse is needed for long-term productivity, efficiency, and profit. The paper presents an empirical investigation of factors influencing speed and reuse in three large product developing organizations seeking to implement Agile practices. The paper identifies, through a multiple case study with 3 organizations, 114 business-, process-, organizational-, architecture-, knowledge- and communication factors with positive or negative influences on reuse, speed or both. Contributions are a categorized inventory of influencing factors, a display for organizing factors for the purpose of process improvement work, and a list of key improvement areas to address when implementing reuse in organizations striving to become more Agile. Categories identified include good factors with positive influences on reuse or speed, harmful factors with negative influences, and complex factors involving inverse or ambiguous relationships. Key improvement areas in the studied organizations are intra-organizational communication practices, reuse awareness and practices, architectural integration and variability management. Results are intended to support process improvement work in the direction of Agile product development. Feedback on results from the studied organizations has been that the inventory captures current situations, and is useful for software process improvement work.