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.

Abstract Code smell is a concept describing potential problems in software design. In opposition, design pattern describes good design solutions in terms of maintainability and reusability. Code smell and design pattern might be perceived as metaphors supporting software design activity in terms of understanding and communication. However, empirical evaluation is needed to investigate their effect in terms of programming activity. Our objective is to build empirical knowledge on the relationship between code smells and design patterns. We carried out an exploratory study based on mining software repositories and in a baseline study addressing software evolution. In total, we analyzed 61 software. Their classes were identified as linked to both code smells and design patterns metaphors. Then, we analyzed the co‐occurrence of these metaphors. Our findings indicate that the relationship between smells and design patterns is software dependent. Some software present many smells linked to design patterns while for other software, smelly classes are not linked to design patterns. We also found that the instability metric weakly reflects this idea. Our study supports better understanding of the topic. It presents results in the opposite direction of expectations that the presence of smells is correlated with the absence of design patterns and vice versa.

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: The concept of code smells is widespread in Software Engineering. However, in spite of the many discussions and claims about them, there are few empirical studies to support or contest these ideas. In particular, the study of the human perception of what is a code smell and how to deal with it has been mostly neglected. Objective: To build empirical support to understand the effect of god classes, one of the most known code smells. In particular, this paper focuses on how conceptualization affects identification of god classes, i.e., how different people perceive the god class concept. Method: A controlled experiment that extends and builds upon another empirical study about how humans detect god classes [19]. Our study: i) deepens and details some of the research questions of the previous study, ii) introduces a new research question and, iii) when possible, compares the results of both studies. Result: Our findings show that participants have different personal criteria and preferences in choosing drivers to identify god classes. The agreement between participants is not high, which is in accordance with previous studies. Conclusion: This study contributes to expand the empirical data about the human perception of code smells. It also presents a new way to evaluate effort and distraction in experiments through the use of automatic logging of participant actions.