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]. Requirements Process Debt (RPD) refers to shortcomings or inefficiencies in the requirements engineering process. Through an industry-wide survey, the InsighTD project identified the causes of RPD, its effects, and practices for its prevention and mitigation. Another approach to exploring RPD is by examining grey literature (GL), i.e., sources that have not been formally published. One such source is the discourse of solution providers, a specific type of web content. Although this discourse can enhance the knowledge gained through empirical studies, no research has yet explored it. [Aims]. To investigate how public discourse has discussed the causes of RPD. [Research Method]. We elicited public discourse on RPD causes using predefined search strings on Google and Bing. We collected web addresses where discussions on RPD causes were found and applied content analysis procedures to examine the data. [Results]. Based on public discourse, we produced 128 codes for causes, 60 for effects of RPD, along with 93 preventive and 70 mitigation practices. These elements were categorized to reveal their relationships within the software development process. [Conclusion]. Our study expands the body of knowledge on RPD causes, demonstrating that GL can serve as a valuable complementary source.

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 . 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.

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: 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.

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.

The coordination and the control of autonomous agent's behavior, in Normative Multi Agent Systems, are important for the achievement of systems' global goal. However, the agents' preferences may not reflect the preferences expected in the organizational system specification. Then, the occurrence of this conflict causes a decrease in system performance. In this context, organizational models and their social structures (norms and sanctions) have been proposed to improve the agent's management and agents behavior. However, specify and apply appropriate sanctions, taking account each agent's level of responsibility, requires an approach that considers individual and collective commitments and their execution. The aim of this work is to propose a mechanism to apply sanctions based on contracts and the hierarchical organization specification, able to be adapted in different application domain. The approach is based in commitment trees, contracts and sanctions in individual and collective levels.

Systems modeling and transformations that are necessary for code generation in the model driven development approach need to realize user interface aspects and persistence infrastructure to create executable software. The developer does not work just with the domain application and also the modeling is more complex whenever more details are needed in the model. Therefore, we propose a development tool where the developer just models the business objects, the associations between objects, and their behaviors using Domain Patterns and Design Patterns. The code is generated based on these Design Patterns and a framework, that implements the architectural patterns Naked Objects, has the responsibility by the infrastructure.