CONTEXT. Focus Group (FG) is a qualitative technique that collects data through moderated group discussion. Although widely used in fields where human behavior is central, their use in Software Engineering (SE) is comparatively less common. In SE, FG applications often need to accommodate technical domains, participants with specialized expertise, and research goals that differ from those typically addressed in traditional social science settings. OBJECTIVE. This study analyzes four FG experiences conducted to investigate distinct SE technologies and topics. The objective is to examine how design decisions, execution strategies, and contextual conditions support or hinder the identification of the benefits and drawbacks of using FGs in SE research. METHOD. We performed a reflective cross-case methodological analysis of four FGs conducted in both academic and industrial settings. The studies differed in goals, group configurations, participant expertise, and moderation strategies. Data sources included session transcripts, written artifacts, moderator observations, and participant feedback. RESULTS. The results indicate that data quality depended on participants’ prior knowledge, the moderator's impartiality, the execution context, and the use of multimodal data capture. Depth and generalizability were limited by time constraints, uneven engagement, and the diverse qualitative data that hindered comparison. CONCLUSIONS. FG is an effective complementary method in SE research, particularly for exploratory analysis and for understanding practitioner perspectives on SE technologies. However, its effectiveness depends on deliberate design choices, including participant selection and preparation, group configuration, and systematic documentation.

Abstract Software quality is undergoing a profound transformation, driven by state-of-the-art research on the application of emerging technologies in software development processes. Specifically, the use of generative Artificial Intelligence (AI) may represent an opportunity to advance the state of practice in this domain. This study aims to assess the industrial readiness and availability of Generative AI-based solutions for software quality, classifying them according to ISO/IEC 25010 attributes and SDLC phases. An empirical assessment of the state of practice was conducted, employing a Rapid Multivocal Literature Review (RMLR) protocol as a data collection instrument to screen evidence from academic databases (Scopus) and grey literature (Google, GitHub, PapersWithCode). We identified 24 potentially usable solutions. However, the analysis reveals a low technological maturity, with most solutions being academic prototypes hampered by fundamental technical limitations and adoption challenges. These include the “last mile problem” in translating research prototypes into reliable, production-ready tools; the “strategic adoption dilemma” forcing practitioners to trade off between proprietary lock-in and high open-source infrastructure costs; and the “scarcity of realistic public data,” which drives a generalization gap due to reliance on synthetic or leaked benchmarks. Generative AI in software quality remains an emerging but immature field, hampered by a critical reliability gap between academic prototypes and industrial needs. Advancing this domain requires moving beyond a narrow code-centric focus to address the quality of the AI systems themselves, expanding research across all SDLC phases and ISO 25010 attributes. We conclude with a roadmap advocating for contamination-free benchmarks, explainable architectures, and robust guidelines for real-world integration.

Refactoring is a non-trivial maintenance activity. Developers spend time and effort refactoring code to remove structural problems, i.e., code smells. Recent studies indicated that developers often apply composite refactoring (composite, for short), i.e., two or more interrelated refactorings. However, prior studies revealed that only 10% of composite refactorings are considered complete, i.e., those fully removing code smells. Many incomplete refactorings can even replace or introduce smells, requiring additional effort for their removal later in the project. Moreover, existing refactoring recommendations are not well-detailed and do not alert developers about these possible side effects. To address these gaps, we conducted a large-scale study involving more than 250k refactorings from 42 software projects, including both open-source and closed-source projects. Our goal is to investigate how the most common complete composites are combined and their side effects in the practice. Our results reveal that the current recommendation to apply Extract Method(s) with fine-grained refactoring types needs refinements. We found that certain fine-grained refactorings like Change Variable Types and Change Return Types can introduce up to 45% of Brain Methods when combined with Extract Method(s). Moreover, Ex-tract Method(s) and Move Method(s), a common recommendation to remove Feature Envy, may inadvertently introduce about 30% of Lazy Classes and approximately 70% of Data Classes. Despite these potential side effects, existing refactoring catalogs and tools' recommenders do not alert developers about these side effects. Finally, we consolidate our findings into a catalog to provide clear guidance for developers and researchers on effectively applying composite refactorings to fully remove code smells.

Robustness is critical for ensuring that software functions correctly under adverse conditions. Exception-handling mechanisms in programming languages enable developers to deal with these adverse conditions. However, implementing exception-related code can present significant challenges to developers. We investigated exception-related code contributions across Java projects in the Apache ecosystem. We analyzed exception-related pull requests (exception-PRs), which were detected using a validated heuristic. We produced a comprehensive dataset of 988 exception-PRs. We observed no statistically significant differences in complexity metrics between exception-PRs and non-exception-PRs. We also found no significant differences in developers' behavior metrics, indicating consistent engagement regardless of whether the pull request addressed exception-related code. A manual analysis revealed that most exception-PRs focused on system improvements rather than bug fixes, suggesting proactive efforts to enhance software robustness. Moreover, the most frequently addressed aspects of exceptional code in these exception-PRs were: (i) the external representation of adverse situations to end-users (more than 40% of the PRs) and (ii) the implementation of effective error-handling actions (nearly 35% of the PRs) to promote program recoverability. Interestingly, a significant proportion of exception-PRs simultaneously addressed multiple aspects. By understanding the nature and characteristics of exception-PRs, we expect to better support developers in managing erroneous conditions and improving software robustness.

The modernization of monolithic legacy systems with microservices has been a trend in recent years. As part of this modernization, identifying microservice candidates starting from legacy code is challenging, as maintainers may consider many criteria simultaneously. Multi-objective search-based approaches represent a promising state-of-the-art solution to support this decision-making process. However, the rationale to adopt each microservice candidate automatically identified by these approaches is poorly investigated in industrial cases. Furthermore, studies with these approaches have not carefully investigated how maintainers reason and make decisions when designing microservice architectures from legacy systems. To address this gap, we conducted an on-site case study with maintainers of an industrial legacy system to investigate the usefulness of automatically generated microservice architectures. We analyze design decisions pointed out by the maintainers when reasoning about microservice candidates using several criteria at the same time. Our study is the first to assess a search-based approach involving actual maintainers conceiving microservice architectures in an industrial setting. Therefore, firstly, we considered individual evaluation of microservice candidates to understand the rationale for identifying a service. Secondly, we conducted a focus group study with maintainers with the goal of investigating design decisions at an architectural level. The results show that:(i)the automated approach is able to identify useful microservices;(ii)the criteria observed by previous studies are, in fact, considered by maintainers; and(iii)the maintainer profiles, i.e., the preferred granularity for microservice, highly affect design decisions. Finally, we observed the maintainers needed little effort in adjusting the automatically identified microservices to make them adoptable. In addition to indicating a promising potential of search-based approaches to generate microservice architectures, our findings highlight the need for:(i)interactive and/or customizable approaches that enable maintainers to include their preferences during the search process, and(ii)flexible or automated selection of criteria that fits the scenario in which the modernization is taking place.

Abstract Substantial research is available on detectinginfluencerson social media platforms. In contrast, comparatively few studies exists on the role ofonline activists, defined informally as users who actively participate in socially-minded online campaigns. Automatically discovering activists who can potentially be approached by organisations that promote social campaigns is important, but not easy, as they are typically active only locally, and, unlike influencers, they are not central to large social media networks. We make the hypothesis that such interesting users can be found on Twitter within temporally and spatially localisedcontexts. We define these as small but topical fragments of the network, containing interactions about social events or campaigns with a significant online footprint. To explore this hypothesis, we have designed an iterative discovery pipeline consisting of two alternating phases of user discovery and context discovery. Multiple iterations of the pipeline result in a growing dataset of user profiles for activists, as well as growing set of online social contexts. This mode of exploration differs significantly from prior techniques that focus on influencers, and presents unique challenges because of the weak online signal available to detect activists. The paper describes the design and implementation of the pipeline as a customisable software framework, where user-defined operational definitions of online activism can be explored. We present an empirical evaluation on two extensive case studies, one concerning healthcare-related campaigns in the UK during 2018, the other related to online activism in Italy during the COVID-19 pandemic.

Context: It is frequently claimed the need for bridging the gap between software engineering research and practice. In this sense, the theory of social representations may be useful to characterize the actual concerns of software developers. It comprises the system of values, behaviors, and practices of communities regarding a particular social object, such as the task of smell identification. Aim: To characterize the social representations of smell identification by software developers. Method: Based on the answers given to a question-naire, we analyzed the associations made by the developers about smell identification, i.e., what immediately comes to their minds when they think about this task. Results: We found that developers strongly associate smell identification with the practice of smell removal and with the incidence of bugs. They also frequently associate the task with the practice of inspection and with the need of having individual skills. Besides, we verified that the current state of the art on smell identification partially address the social representations of the software developers. Conclusion: There is a considerable gap between the research of smell identification and its practice. We propose directions to mitigating this gap.

The prevalence of design problems may cause re-engineering or even discontinuation of the system. Due to missing, informal or outdated design documentation, developers often have to rely on the source code to identify design problems. Therefore, developers have to analyze different symptoms that manifest in several code elements, which may quickly turn into a complex task. Although researchers have been investigating techniques to help developers in identifying design problems, there is little knowledge on how developers actually proceed to identify design problems. In order to tackle this problem, we conducted a multi-trial industrial experiment with professionals from 5 software companies to build a grounded theory. The resulting theory offers explanations on how developers identify design problems in practice. For instance, it reveals the characteristics of symptoms that developers consider helpful. Moreover, developers often combine different types of symptoms to identify a single design problem. This knowledge serves as a basis to further understand the phenomena and advance towards more effective identification techniques.

Context: Code smells are symptoms in the source code that represent poor design choices. Professional developers often perceive several types of code smells as indicators of actual design problems. However, the identification of code smells involves multiple steps that are subjective in nature, requiring the engagement of humans. Human factors are likely to play a key role in the precise identification of code smells in industrial settings. Unfortunately, there is limited knowledge about the influence of human factors on smell identification. Goal: We aim at investigating whether the precision of smell identification is influenced by three key human factors, namely reviewer's professional background, reviewer's module knowledge and collaboration of reviewers during the task. We also aim at deriving recommendations for allocating human resources to smell identification tasks. Method: We performed 19 comparisons among different subsamples from two trials of a controlled experiment conducted in the context of an empirical study on code smell identification. One trial was conducted in industrial settings while the other had involved graduate students. The diversity of the samples allowed us to analyze the influence of the three factors in isolation and in conjunction. Results: We found that (i) reviewers' collaboration significantly increases the precision of smell identification, but (ii) some professional background is required from the reviewers to reach high precision. Surprisingly, we also found that: (iii) having previous knowledge of the reviewed module does not affect the precision of reviewers with higher professional background. However, this factor was influential on successful identification of more complex smells. Conclusion: We expect that our findings are helpful to support researchers in conducting proper experimental procedures in the future. Besides, they may also be useful for supporting project managers in allocating resources for smell identification tasks.

Code smells in a program represent indications of structural quality problems, which can be addressed by software refactoring. However, refactoring intends to achieve different goals in practice, and its application may not reduce smelly structures. Developers may neglect or end up creating new code smells through refactoring. Unfortunately, little has been reported about the beneficial and harmful effects of refactoring on code smells. This paper reports a longitudinal study intended to address this gap. We analyze how often commonly-used refactoring types affect the density of 13 types of code smells along the version histories of 23 projects. Our findings are based on the analysis of 16,566 refactorings distributed in 10 different types. Even though 79.4% of the refactorings touched smelly elements, 57% did not reduce their occurrences. Surprisingly, only 9.7% of refactorings removed smells, while 33.3% induced the introduction of new ones. More than 95% of such refactoring-induced smells were not removed in successive commits, which suggest refactorings tend to more frequently introduce long-living smells instead of eliminating existing ones. We also characterized and quantified typical refactoring-smell patterns, and observed that harmful patterns are frequent, including: (i) approximately 30% of the Move Method and Pull Up Method refactorings induced the emergence of God Class, and (ii) the Extract Superclass refactoring creates the smell Speculative Generality in 68% of the cases.

Context: The representativeness of samples in Software Engineering primary studies is still a great challenge, mainly when identifying available sources for establishing adequate sampling frames, characterizing subjects and stimulating their participation in (opinion) surveys. The lack of survey guidelines taking into account the specificities of Software Engineering increases the research challenge. Goal: To introduce a conceptual framework for supporting the identification of representative samples for surveys in Software Engineering. Method: Based on knowledge acquired in the technical literature and researchers' experience, to organize a set of guidelines to systematically support sampling in Software Engineering surveys. To perform in vitro empirical studies to observe and evolve the guidelines. Results: An empirically evaluated set of planning activities and tasks with recommendations to support the identification of representative samples for surveys in Software Engineering is available. Conclusion: Surveys have been supporting relevant investigations in Software Engineering in the last decades. This conceptual framework can contribute to strength representativeness of their results. However, some important issues regarding survey research are still open and deserves attention from the empirical Software Engineering community.

Context: The results of large-scale studies in software engineering can be significantly impacted by samples' representativeness. Diverse population sources can be used to support sampling for such studies. Goal: To compare two samples, one from the crowdsourcing platform Mechanical Turk and another from the professional social network LinkedIn, in an online experiment for evaluating the relevance of Java code snippets to programming tasks. Method: To compare the samples (subjects' experience, programming habits) and experimental results concerned with three experimental trials. Results: LinkedIn's subjects present significantly higher levels of experience in Java programming and programming in general than Mechanical Turk's subjects. The experimental results revealed a significant difference between samples and suggested that LinkedIn's subjects were more pessimistic than Mechanical Turk's subjects despite a high level consistency in the experimental results. Conclusion: The combined use of sources of sampling can bring benefits to large scale studies in software engineering, especially when heterogeneity is desired in the population. Thus, it can be useful to investigate and characterize alternative sources of sampling for performing large-scale studies in software engineering.

Context: The low quality and small size of samples in empirical studies in software engineering hamper the interpretation and generalization of their results. Therefore, enlarging sample sizes and improving their quality represent an important research challenge. Goal: We aim to define a conceptual framework, including requirements for establishing adequate sources for sampling subjects in software engineering surveys. Method: We use previous experience on applying systematic sampling strategies combined with contemporary web technologies in previously executed surveys, to organize the conceptual framework. We analyze its application to different sources of sampling. Results: The framework was observed to be feasible after its application to nine different large-scale sources of sampling. Conclusions: The analyzed crowdsourcing tools do not support essential requirements to be considered sources of sampling, while free-lancing tools and professional social network do.

Context: Small and non-probabilistic samples represent relevant issues when discussing the external validity of empirical studies in Software Engineering. Goal: To investigate alternatives to improve the quality of samples (size, heterogeneity and level of confidence). Method: To replicate a survey on characteristics of agility in software processes by applying a systematic recruitment strategy over a professional social network. Results: It resulted in a sampling frame composed by 19 groups stratified according two perspectives: sharing of groups' members and main software engineering skills reported by the subjects. In total, 7,745 subjects were randomly recruited, resulting in 291 contributions. Conclusions: This sample was significantly larger, more heterogeneous and presents some strata with higher confidence levels than previous trials samples.

Context: Two of the most common external threats to validity in quantitative studies in software engineering (SE) are concerned with defining the population by convenience and nonrandom sampling assignment. Although these limitations can be reduced by increasing the number of replications and aggregating their results, the acquired evidence rarely can be generalized to the field.

Quantitative studies in Software Engineering are frequently dependent on primary studies in which population is usually small and established by convenience. It brings several limitations for the analysis and strength of results due sampling issues. Therefore, when these studies are reapplied, different and non-clustered populations are established, making unfeasible evidence generalization and contributing for an imbalance between research and practice. Aiming at investigating ways to overcome the absence of large sampling frames in Software Engineering studies, this short paper presents the results of an initial experience concerned with the systematic recruitment of subjects for a survey regarding software requirements effort factors by using social networks compared with recruitment by convenience. We have observed in this particular case that using social networks technology does not guarantee sample enlargement by just posting invitations in specific forums. However, its usage can contribute to increase the subjects' heterogeneity and to increase the level of confidence of the sample, which consequently improve our capacity of observing the object under study, with the probable strengthen of results.