Context . Empathy, a key social skill, is essential for communication and collaboration in SE but remains an under-researched topic. Aims . This study investigates empathy in SE from practitioners’ perspectives, aiming to characterize its meaning, identify barriers, discuss practices to overcome them, and explore its effects. Method . A qualitative content analysis was conducted on 55 web articles from DEV and Medium, two communities widely used by practitioners. To strengthen our findings, we conducted a follow-up survey with empathy experts. Results . The study proposes a definition of empathy in SE, identifies barriers such as toxic culture and excessive technical focus, practices to foster empathy in teams, and outcomes, including improved collaboration, communication, and reduced anxiety, frustration, and stress. These findings are synthesized into a conceptual framework. Conclusion . Survey results indicate the framework is clear, valuable, and raises empathy awareness, with suggestions for improvements and integration into training. This study paves the way for improving team dynamics by addressing barriers and offering strategies to cultivate empathy. Future work will explore empathy’s broader implications in SE practice.

This is the Replicated Computational Results (RCR) Report for our TOSEM article “Exploring Empathy in Software Engineering: Insights from a Gray Literature Analysis of Practitioners’ Perspectives” where we present qualitative content analysis conducted on 55 web articles from DEV and Medium, two communities widely used by practitioners, and a follow-up survey with empathy experts. In this article, we introduced a conceptual framework of empathy in software engineering. As part of this RCR, we provide an empirical package with detailed guidelines to set up and replicate our study, as well as to interpret the results. We hope it can motivate and support future research on empathy and human aspects in software engineering by offering a reusable and transparent example of qualitative analysis involving gray literature and expert feedback. All related data and materials are openly available in the experimental package.

[Context] Technical debt (TD) in machine learning (ML) systems, much like its counterpart in software engineering (SE), holds the potential to lead to future rework, posing risks to productivity, quality, and team morale. Despite growing attention to TD in SE, the understanding of ML-specific code-related TD remains underexplored. [Objective] This paper aims to identify and discuss the relevance of code-related issues that lead to TD in ML code throughout the ML workflow. [Method] The study first compiled a list of 34 potential issues contributing to TD in ML code by examining the phases of the ML workflow, their typical associated activities, and problem types. This list was refined through two focus group sessions involving nine experienced ML professionals, where each issue was assessed based on its occurrence contributing to TD in ML code and its relevance. [Results] The list of issues contributing to TD in the source code of ML systems was refined from 34 to 30, with 24 of these issues considered highly relevant. The data pre-processing phase was the most critical, with 14 issues considered highly relevant. Shortcuts in code related to typical pre-processing tasks (e.g., handling missing values, outliers, inconsistencies, scaling, rebalancing, and feature selection) often result in “patch fixes” rather than sustainable solutions, leading to the accumulation of TD and increasing maintenance costs. Relevant issues were also found in the data collection, model creation and training, and model evaluation phases. [Conclusion] We have made the final list of issues available to the community and believe it will help raise awareness about issues that need to be addressed throughout the ML workflow to reduce TD and improve the maintainability of ML code.

Context. Stroke remains a leading cause of long-term disability, prompting growing interest in emerging technologies like artificial intelligence (AI) and virtual reality (VR) to improve treatments. The combination of AI’s adaptability and VR’s immersive environments holds promise for personalized, engaging, and scalable stroke care, though research in this area remains fragmented. Objective. This study provides an overview of current research on the combined use of AI and VR in stroke care, focusing on system types, clinical validation, technologies employed, and autonomy levels. Method. We conducted a systematic mapping study of papers published between 2014 and 2024. Results. We identified 73 relevant studies. Most systems are still in early prototype or usability-testing stages, with limited clinical validation and frequent human oversight. Technologies used are diverse, and longitudinal evaluations are rare. Conclusion. Significant research gaps persist, including limited validation, lack of pre-stroke applications, and fragmented tools. These findings offer guidance for developing more robust, clinically viable, and interoperable AI and VR systems for stroke care.

Ensuring fairness in software systems has become a critical concern in software engineering. Motivated by this challenge, this article explores the multifaceted nature of bias in software systems, providing a comprehensive understanding of its origins, manifestations, and impacts. Through a scoping study, we identified the primary causes of fairness deficiencies in software development and highlighted their adverse effects on individuals and communities, including instances of discrimination and the perpetuation of inequalities. Our investigation culminated in the introduction of the concept of software fairness debt. In addition to defining fairness debt, we propose a socio-technical roadmap that addresses broader aspects of fairness in AI-driven systems. This roadmap is structured around six goals: bridging the gap between research and real-world applications, developing a framework for fairness debt, equipping practitioners with tools and knowledge, improving bias mitigation, integrating fairness tools into industry practice, and enhancing explainability and transparency in AI systems. This roadmap provides a holistic approach to managing biases in software systems through software fairness debt, offering actionable steps for both research and practice. By guiding researchers and practitioners, our roadmap aims to foster the development of more equitable and socially responsible software systems, ensuring fairness is embedded throughout the software lifecycle.

Context: This study explores how software professionals identify and address biases in AI systems within the software industry, focusing on practical knowledge and real-world applications. Goal: We focused on understanding the strategies employed by practitioners to manage bias and their implications for fairness debt. Method: We employed a qualitative research method, gathering insights from industry professionals through interviews and using thematic analysis to explore the collected data. Findings: Professionals identify biases through discrepancies in model outputs, demographic inconsistencies, and training data issues. They address these biases using strategies such as enhanced data management, model adjustments, crisis management, improving team diversity, and ethical analysis. Conclusion: Our paper presents initial evidence on addressing fairness debt and lays the groundwork for developing structured guidelines to manage fairness-related issues in AI systems.

Programming industrial robots is difficult and expensive. Although recent work has made substantial progress in making it accessible to a wider range of users, it is often limited to simple programs and its usability remains untested in practice. In this article, we introduce Duplo, a block-based programming environment that allows end-users to program two-armed robots and solve tasks that require coordination. Duplo positions the program for each arm side-by-side, using the spatial relationship between blocks from each program to represent parallelism in a way that end-users can easily understand. This design was proposed by previous work, but not implemented or evaluated in a realistic programming setting. We performed a randomized experiment with 52 participants that evaluated Duplo on a complex programming task that contained several sub-tasks. We compared Duplo with RobotStudio Online YuMi, a commercial solution, and found that Duplo allowed participants to solve the same task faster and with greater success. By analyzing the information collected during our user study, we further identified factors that explain this performance difference, as well as remaining barriers, such as debugging issues and difficulties in interacting with the robot. This work represents another step towards allowing a wider audience of non-professionals to program, which might enable the broader deployment of robotics.

Context . Technical debt (TD) prevention allows software practitioners to apply practices to avoid potential TD items in their projects. Aims . To uncover and prioritize, from the point of view of software practitioners, the practices that could be used to avoid TD items, the relations between these practices and the causes of TD, and the practice avoidance reasons (PARs) that could explain the failure to prevent TD. Method . We analyze data collected from six replications of a global industrial family of surveys on TD, totaling 653 answers. We also conducted a follow up survey to understand the importance level of analyzed data. Results . Most practitioners indicated that TD could be prevented, revealing 89 prevention practices and 23 PARs for explaining the failure to prevent TD. The article identifies statistically significant relationships between preventive practices and certain causes of TD. Further, it prioritizes the list of practices, PARs, and relationships regarding their level of importance for TD prevention based on the opinion of software practitioners. Conclusion . This work organizes TD prevention practices and PARs in a conceptual map and the relationships between practices and causes of TD in a Sankey diagram to help the visualization of the body of knowledge reported in this study.

Advances in technical debt research demonstrate the benefits of applying the financial debt metaphor to support decision-making in software development activities. Although decision-making during requirements engineering has significant consequences, the debt metaphor in requirements engineering is inadequately explored. We aim to conceptualize how the debt metaphor applies to requirements engineering by organizing concepts related to practitioners’ understanding and managing of requirements engineering debt (RED). We conducted two in-depth expert interviews to identify key requirements engineering debt concepts and construct a survey instrument. We surveyed 69 practitioners worldwide regarding their perception of the concepts and developed an initial analytical theory. We propose a RED theory that aligns key concepts from technical debt research but emphasizes the specific nature of requirements engineering. In particular, the theory consists of 23 falsifiable propositions derived from the literature, the interviews, and survey results. The concepts of requirements engineering debt are perceived to be similar to their technical debt counterpart. Nevertheless, measuring and tracking requirements engineering debt are immature in practice. Our proposed theory serves as the first guide toward further research in this area.

Context: Technical debt (TD) can bring short-term benefits to software projects, but its presence is also associated with issues such as decreasing product quality. Recent literature has proposed indicator-based strategies for TD identification and different approaches for TD management, but most of them focused on the point of view of software developers. Little is still known about how project management practitioners actually discuss, experience, and manage TD. Goal: This work investigates, from the point of view of project management practitioners, how they commonly discuss, experience, and manage TD. Method: We mined, curated, and selected a total of 42 TD discussions on Stack Exchange Project Management (SEPM), totaling 583 messages. We analyzed this data set quantitatively and qualitatively. Results: The most commonly discussed types of debt are process and people, revealing 47 indicators for recognizing debt items. We also found 72 practices related to TD management. Conclusion: The perspective considered by project management practitioners to analyze the TD phenomenon is different from the one considered by other roles in the software development process. This work organizes the TD indicators and management practices identified in SEPM into a Sankey diagram, which may assist practitioners and serve as guidance for future research.

Context: Technical debt (TD) is a challenge for companies who develop software on which their critical operations depend. To properly manage TD, it is necessary to make it visible to the different stakeholders involved to support informed decisions. Objective: To validate a TD visualization approach based on hybrid Sankey diagrams that makes the TD visible by showing (a) technical and business aspects, and (b) the flow of value and TD impacts. This approach regards visualizations as boundary objects. Method: We performed a multi-case study in a large multi-industry state-owned company. The objective was to validate the effectiveness of such visualizations and to explore their possible uses in TD management. We first used a retrospective case study on a TD decision-making scenario and, later, visualization usage scenarios using focus groups to evaluate its usefulness. Results: The results suggest that the proposed approach: (a) provides a structured process for systematic TD visualization to help the decision-making process; (b) enables the communication at knowledge boundaries between stakeholders to make informed decisions; (c) uses flow representations that are important for assessing the impact in multiple functional areas; and (d) enables documentation and reuse. Conclusion: The study results suggest that TD decision-making events can benefit from using our TD visualizations based on hybrid Sankey diagrams as boundary objects to portray the impact of TD in business, services, and technical aspects.

Context: Knowing the effects of technical debt (TD) can support software development teams in the prioritization of TD items to pay off. However, little is known about the relations between the effects of TD and TD payment practices. Having this knowledge can provide valuable information for decision making about which payment practice can be applied given the presence of specific effects of TD. Aims: To investigate, from the point of view of software practitioners, (i) which TD payment practices have been used when certain effects of the presence of debt are felt in software projects and (ii) the reasons for not paying debt items despite the effects they are causing to the project. Method: We analyze quantitatively and qualitatively data collected from a survey with 432 practitioners across four countries. Results: Among the identified relations, the practice "code refactoring" is commonly used to pay debt items off when the effects "delivery delay" and "rework" are felt in software projects. On the other hand, when practitioners face the TD effects "low external quality" and "delivery delay", ，they commonly justify the non- payment of the debt items indicating the need of "focusing on short term goals". Conclusion: We organize the relationship between TD effects, and payment practices and reasons for not eliminating debt items. All this information is structured in an alluvial diagram, which can facilitate the visualization of the identified relations.

Background: Little is known about the practices used for technical debt (TD) payment. The study of payment practices, as well as the reasons for not applying them, can help practitioners to control and manage TD items. Aims: To investigate, from the point of view of software practitioners, if TD items have been paid off in software projects, the practices that have been used to pay off TD and the reasons that hamper the implementation of these practices. Method: We analyzed - both quantitatively and qualitatively - a corpus of responses from a survey of 432 practitioners, from four countries, about the possibility of TD payment. Results: We found that, for most of the cases, TD items have not been eliminated from software projects. The main reasons for not paying off TD are lack of organizational interest, low priority on the debt, focus on short-term goals, cost, and lack of time. On the other hand, we identified that code refactoring, design refactoring, and update system documentation are the most used practices for TD payment. Practitioners also cited practices related to the prevention, prioritization, and creation of a favorable setting as part of TD payment initiatives. Conclusion: This paper summarizes the identified practices and reasons for not paying off debt items in a map. Our map reveals that the majority of payment practices are of a technical nature while the majority of reasons for not paying off debts are associated with non-technical issues.

Context: System modeling usually precedes coding activities during software development. Addressing model smells in the upfront can avoid their propagation to the source code. Technical debt (TD) affects several software development phases, including design, but little is still known about it at the modeling level. Goal: Investigate whether applying refactoring procedures in UML class diagrams improves the quality of the automatically generated code in terms of TD (code debt) reduction. Method: We perform three replications of an empirical study following the same protocol used in the original study, but with variations on the: (1) round- trip engineering tool, (2) code issue identification tool, and (3) analyzed class diagram. Each study considered two sets of refactoring tasks. The first applied successive model refactoring sessions in a class diagram and analyzed their resulting automatically generated code. The second applied successive code refactoring sessions and analyzed their resulting automatically generated model. Results: There is a weak relationship between the analyzed model smells and code issues. Round-trip engineering tools influence the presence of code issues. Lastly, code issues identification tools mostly consider code formatting problems, in detriment of design issues smells. Conclusion: Results confirm the findings of the original study and motivate further investigation on the correspondence between model smells and code issues to prevent code debt at the model level.

Background: The concept of technical debt (TD) describes a phenomenon that impacts software projects and makes them difficult to manage. In recent years, various techniques and best practices in terms of TD management were proposed and although important on its own this knowledge must be complemented with a broader comprehension of what causes TD and what are the effects of TD. This paper presents a replication of the InsighTD survey-a globally distributed family of industrial surveys on causes and effects of TD-and thus amplifies the InsighTD reach and expands its knowledge base. Objective: The research presented in this paper gives insight on the state of practice and understanding of the TD concept alongside with data on causes and effects of TD in the Serbian IT industry. Method: A nation-wide survey, as a part of the InsighTD initiative, was conducted in Serbia in order to obtain feedback from software industry practitioners. Results: In total 93 practitioners from the Serbian IT industry filled out the survey. The results indicate that the concept of TD is broadly distributed, but at the same time it is not widely accepted for use (only 35% of participants had some sort of practical experiences with projects that were TD aware). The top cited causes were: deadlines, ineffective project management, lack of experience, test not performed and misconduct. On the other side the most common effects of TD were: low maintainability, increased effort, rework and low external quality. Conclusion: The research presented in this paper confirms the original study findings that deadlines are the top cited cause of TD. It also identifies new causes of TD in the context of InsighTD, with misconduct being one of the most cited ones. Regarding the effects of TD this research differs in most of the top 10 identified effects from the original study but confirms the occurrence of some effects most cited.

Context: Technical debt (TD) is a metaphor used to describe technical decisions that can give the company a benefit in the short term but possibly hurting the overall quality of the software in the long term. Objective: This study aims to characterize the current state of practices related to TD payment from the point of view of software practitioners. Method: We used a survey research method to collect and analyze - both quantitatively and qualitatively - a corpus of responses from a survey of 432 software practitioners from Colombia, Chile, Brazil, and the United States, as a part of the InsighTD project. Results: We were able to identify that refactoring (24.3%) was the main practice related to TD payment, along with improving testing (6.2%) and improve design (5.8%). Also, we identify that small-sized systems and big-sized systems, along with young systems (less than one year) tend to use more refactoring. As a part of these results, we also could identify that some practices do not eliminate the debt by itself, but support a favorable scenario for TD payment or prevention. Additionally, after comparing the three major TD types cited (code debt, test debt and design debt) we could discover an important similarity of TD payment practices between code debt and design debt. Lastly, we identified that no matter the cause leading to TD occurrence, refactoring remained the most common practice. Conclusion: Definition of practices related to TD payment is an essential activity for software development teams. Developing healthy software systems that can be maintained in the future requires that companies find the right approaches for TD payment.

Background: Over the years, several studies were conducted aiming at understanding the Technical Debt (TD) phenomenon and its implications on software development. Most of these studies focus on source code related TD types. The absence of empirical studies on usability debt motivated our research. Aims: The goal of this paper is to provide an initial usability debt characterization in software projects regarding its occurrence, type, and resolution effort. Method: We conducted a multi-case study, analyzing TD items of five software projects from four different companies. Results: We identified and classified 145 TD items in the projects. The analysis of these items allowed us to observe that the frequency of usability TD items ranged from 10.4% to 20.8% in the projects. The usability debt items cover a range of usability issues, violating eight out of the ten Nielsen usability heuristics. Regarding effort for paying the TD, usability debt items require a relatively low effort, ranging from 5.1% to 6.7% of the total TD resolution effort in the analyzed projects. Conclusions: Usability TD items are frequent, concern relevant usability issues and typically require low effort for their payment. Hence, paying this type of TD should receive high priority in TD management strategies.

Understanding TD causes can support development teams in defining actions that could be taken to prevent the occurrence of debt items. Understanding the effects of TD could aid in prioritization of TD items to pay off to minimize possible negative consequences for the project. Existing work has revealed 105 causes and 85 effects of TD, and this high number can make it difficult to make practical use of this information. Without a consolidated representation, we would need to rely on a set of tables and isolated pieces of data. In this work, we propose the use of cross-company probabilistic cause-effect diagrams to represent information about TD causes and effects. We hypothesize that such diagrams can be useful to support TD cause/effect analysis sessions and empirically investigate this issue. Results from a case study performed with 72 participants indicate that the diagrams are able to positively support the management of TD, making it easier to identify its causes and the effects of its presence. Most of the participants also agreed that, by using the proposed diagrams, they gain agility, productivity, performance, and effectiveness. Finally, 89% of the participants stated that the use of the diagrams helped them to identify causes and effects of TD that they would not have identified without their support.

Requirements Engineering (RE) has established itself as a software engineering discipline over the past decades. While researchers have been investigating the RE discipline with a plethora of empirical studies, attempts to systematically derive an empirical theory in context of the RE discipline have just recently been started. However, such a theory is needed if we are to define and motivate guidance in performing high quality RE research and practice. We aim at providing an empirical and externally valid foundation for a theory of RE practice, which helps software engineers establish effective and efficient RE processes in a problem-driven manner. We designed a survey instrument and an engineer-focused theory that was first piloted in Germany and, after making substantial modifications, has now been replicated in 10 countries worldwide. We have a theory in the form of a set of propositions inferred from our experiences and available studies, as well as the results from our pilot study in Germany. We evaluate the propositions with bootstrapped confidence intervals and derive potential explanations for the propositions. In this article, we report on the design of the family of surveys, its underlying theory, and the full results obtained from the replication studies conducted in 10 countries with participants from 228 organisations. Our results represent a substantial step forward towards developing an empirical theory of RE practice. The results reveal, for example, that there are no strong differences between organisations in different countries and regions, that interviews, facilitated meetings and prototyping are the most used elicitation techniques, that requirements are often documented textually, that traces between requirements and code or design documents are common, that requirements specifications themselves are rarely changed and that requirements engineering (process) improvement endeavours are mostly internally driven. Our study establishes a theory that can be used as starting point for many further studies for more detailed investigations. Practitioners can use the results as theory-supported guidance on selecting suitable RE methods and techniques.

Background: The presence of technical debt (TD) brings risks to a software project and makes it difficult to manage. Several TD management strategies have been proposed, but considering actions that could explicitly prevent the insertion of TD in the first place and monitor its effects is not yet a common practice. Thus, while TD management is an important topic, it is also worthwhile to understand the causes that could lead development teams to incur different types of debt as well as the effects of their presence on software projects. Aims: The objective of this work is twofold. First, we investigate the state of practice in the TD area including the status quo, the causes that lead to TD occurrence, and the effects of existing TD. Second, we present the design of InsighTD, a globally distributed family of industrial surveys on causes and effects of TD, and the results of its first execution. Method: We designed the InsighTD in joint collaboration with several TD researchers. It is designed to run as an incremental large scale study based on continuous and independent replications of the questionnaire in different countries. Results: This paper presents the first results of the first execution of the survey. In total, 107 practitioners from the Brazilian software industry answered the questionnaire. Results indicate that there is a broad familiarity with the concept of TD. Deadlines, inappropriate planning, lack of knowledge, and lack of a well-defined process are among the top 10 cited and most likely causes that lead to the occurrence of TD. On the other side, low quality, delivery delay, low maintainability, rework and financial loss are among the top 10 most commonly cited and impactful effects of TD. Conclusion: With InsighTD, we intend to reduce the problem of isolated investigations in TD that are not yet representative and, thus, build a continuous and generalizable empirical basis for understanding practical problems and challenges of TD.

Context: Several technical debt (TD) management strategies have been proposed, but considering actions that could prevent the insertion of TD in the first place is not yet a common practice. This is a point that deserves investigation because it is expected that TD prevention could be sometimes "cheaper" than TD repayment. Besides, TD prevention also helps other TD management activities, especially in catching inexperienced developers' 'not-so-good' solutions. Thus, while TD management is an important topic, it is also worthwhile to understand the motivations and factors that could lead development teams to incur different types of debt. Objective: To identify causes that lead to the occurrence of TD, investigate if these causes occur in isolation or in combination, understand if TD can be prevented, and investigate, in terms of effort, if it is better to prevent debt, or incur it and pay it off later. Method: An interview based case study was performed with software practitioners. The results were formulated based on a synthesis of the text fragments coded for each response. Results: We identified 57 causes that lead a development team to incur debt. For the majority of TD types, these causes occur in combination. It was also indicated that debt can be prevented, and it is better to work on prevention activities than to pay off debt later. Conclusion: Results allowed us to identify 57 causes that lead a development team to incur debt. These causes mostly occur in combination, not in isolation. It was also indicated that debt can be prevented, and it would be better to work on prevention activities than to pay off debt later.

The current scenario of software development is characterized by a wide adoption of agile methodologies, which define processes and practices that address a range of problems faced by development teams.However, there is still little information on how these methodologies deal with technical debt(TD).This work presents the results of a replicated survey(originally executed in Finland) whose goal was to investigate which agile practices and processes are sensitive to TD.Despite this replication allows different types of analysis, the focus of this paper will be on the analysis of the effects of the agile practices and processes on TD from the perspective of the Brazilian software industry, where the study was replicated.At total, 62 practitioners from different organizations answered the questionnaire.The results indicated that participants already had a good knowledge about TD, instances of TD reside in the software implementation and are caused due to deficiencies in its architecture, the size of a debt item is proportional to its impact on the project, and, refactoring and iteration have the most positive effect on TD.This replication also contributes to the investigated topic through the accumulation of evidence about the findings, thereby increasing the level of confidence in results.

Context: Mining software repositories has been used as an important tool to support software engineering research.Recent studies indicate that code comments are one of the most explored objects of analysis in the area.Objective: This work investigates how analysis of comments has been used to support software engineering activities by identifying its purposes, focuses, techniques, tools, evaluation methods, and the research type performed in the area.Method: We performed a systematic mapping study of the literature that considered papers from 1990 to 2016.Results: We analyzed 36 primary studies.The collected data pointed out that comment analysis has been used mainly for understanding and identifying the quality of software artifacts.The Dictionary/Vocabulary and Natural Language Processing are among the most used techniques, and most of them are performed in a semiautomatic way.We also organized a set of tools that have been used for mining software comments.Most of the primary studies are a solution proposal paper.Regarding evaluation methods, we found that experiments and case studies are the most considered.Conclusion: The results of this mapping study can help to identify points that still require further investigation in comment analysis research.

Context] The software engineering community considers the technical debt (TD) concept intuitive, because it facilitates discussion among team members about problems that can impact the software development.Personal opinions and experiences related to the concept have been published in blogs and other channels without any evaluation, originating the TD Folklore.[Goal] This work aims to investigate TD Folklore statements classifying them by agreement and consensus.Besides, we also investigated if software development experience affects the perception of developers.[Method] We replicated a survey to evaluate TD Folklore statements.In the replication, we increased the number of respondents and added a new research question to analyze the difference of opinions between participants with and without software experience.[Results] At total, the survey was answered by 107 respondents.The list of TD Folklore was reorganized by the ranking of agreement and consensus indicated by participants.We also identified that professional experience does not change the participants´ perception on the concept of TD for the most cases.[Conclusion] We believe that TD Folklore can help researchers and practitioners identify gaps for new research efforts.

Context: Contemporary software development is typically conducted in dynamic, resource-scarce environments that are prone to the accumulation of technical debt. While this general phenomenon is acknowledged, what remains unknown is how technical debt specifically manifests in and affects software processes, and how the software development techniques employed accommodate or mitigate the presence of this debt. Objectives: We sought to draw on practitioner insights and experiences in order to classify the effects of agile method use on technical debt management, given the popularity and perceived success of agile methods. We explore the breadth of practitioners’ knowledge about technical debt; how technical debt is manifested across the software process; and the perceived effects of common agile software development practices and processes on technical debt. In doing so, we address a research gap in technical debt knowledge and provide novel and actionable managerial recommendations. Method: We designed, tested and executed a multi-national survey questionnaire to address our objectives, receiving 184 responses from practitioners in Brazil, Finland, and New Zealand. Results: Our findings indicate that: 1) Practitioners are aware of technical debt, although, there was under utilization of the concept, 2) Technical debt commonly resides in legacy systems, however, concrete instances of technical debt are hard to conceptualize which makes it problematic to manage, 3) Queried agile practices and processes help to reduce technical debt; in particular, techniques that verify and maintain the structure and clarity of implemented artifacts (e.g., Coding standards and Refactoring) positively affect technical debt management. Conclusions: The fact that technical debt instances tend to have characteristics in common means that a systematic approach to its management is feasible. However, notwithstanding the positive effects of some agile practices on technical debt management, competing stakeholders’ interests remain a concern.

Technical debt (TD) refers to likely long-term costs associated with software development shortcuts taken by programmers to achieve short-term business benefits. If a development team does not manage TD, it can cause significant long-term problems such as high maintenance costs. Management strategies monitor debt items and evaluate when and if they should be paid. In order to effectively support this task, the systematic use of decision criteria can be decisive. In this context, this paper presents a strategy for TD management that uses multiple decision criteria to decide when to pay debt items off. In addition, it presents a case study that assessed the feasibility of the proposed strategy regarding its usefulness, ease of use and self-predicted future use. The results provided positive evidence on the use of the proposed strategy, indicating (i) that it can be useful in supporting TD management activities and (ii) that it can bring gains in terms of productivity, performance, and efficacy when evaluating the desirable time to pay debt items off.

In seeking to complement consultants' and tool vendors' reports, there has been an increasing academic focus on understanding the adoption and use of software development methods and practices. We surveyed practitioners working in Brazil, Finland, and New Zealand in a transnational study to contribute to these efforts. Among our findings we observed that most of the 184 practitioners in our sample focused on a small portfolio of projects that were of short duration. In addition, Scrum and Kanban were used most; however, some practitioners also used conventional methods. Coding Standards, Simple Design and Refactoring were used most by practitioners, and these practices were held to be largely suitable for project and process management. Our evidence points to the need to properly understand and support a wide range of software methods.

Context] Many software projects fail due to problems in requirements engineering (RE).[Objective] The goal of this paper is to gather information on relevant RE problems and to represent knowledge on their most common causes.[Method] We replicated a global family of RE surveys in Brazil and used the data to identify critical RE problems and to build probabilistic causeeffect diagrams to represent knowledge on their common causes.[Results] The survey was answered by 74 different organizations, including small, medium and very large sized companies, conducting both, plan-driven and agile development.The most critical RE problems, according to those organizations, are related to communication and to incomplete or underspecified requirements.We provide the full probabilistic cause-effect diagrams with knowledge on common causes of the most critical identified RE problems online.[Conclusion] We believe that the knowledge presented in the diagrams can be helpful to support organizations in conducting causal analysis sessions by providing an initial understanding on what usually causes critical RE problems.

Context: The technical debt (TD) concept describes a tradeoff between short-term and long-term goals in software development. While it is highly useful as a metaphor, it has utility beyond the facilitation of discussion, to inspire a useful set of methods and tools that support the identification, measurement, monitoring, management, and payment of TD. Objective: This study focuses on the identification of TD. We evaluate human elicitation of TD and compare it to automated identification. Method: We asked a development team to identify TD items in artifacts from a software project on which they were working. We provided the participants with a TD template and a short questionnaire. In addition, we also collected the output of three tools to automatically identify TD and compared it to the results of human elicitation. Results: There is little overlap between the TD reported by different developers, so aggregation, rather than consensus, is an appropriate way to combine TD reported by multiple developers. The tools used are especially useful for identifying defect debt but cannot help in identifying many other types of debt, so involving humans in the identification process is necessary. Conclusion: We have conducted a case study that focuses on the practical identification of TD, one area that could be facilitated by tools and techniques. It contributes to the TD landscape, which depicts an understanding of relationships between different types of debt and how they are best discovered.