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.

Technical debt (TD) expresses the lack of internal quality directly affecting software evolution. Therefore, it has gained the attention of software researchers and practitioners recently. Software researchers have performed empirical studies to observe the perspective of TD in different software cultures and organizations. However, it is important to replicate such studies in more places and with more practitioners to strengthen the perception of TD. In this paper, we present the results of a set of new research questions from an evolved survey design of a survey replication in the Uruguayan software industry to characterize how the software industry professionals understand, perceive, and adopt TD management (TDM) activities. The results allow us to observe that different participant contexts (startups, government, job roles) show different levels of awareness and perception of TD. Details in the form of the adoption of each TDM activity were presented. We could observe some difficulties in conducting some TDM activities that the practitioners consider very important, especially in TDM and monitoring. Differences in specific organizational contexts like startups and government could indicate the need for research efforts in other software engineering communities that meet their specific TD challenges and needs.

Background: Technical debt (TD) has been an important focus of attention in recent years by the scientific community and the software industry. TD is a concept for expressing the lack of internal software quality that directly affects its capacity to evolve. Some studies have focused on the TD industry perspective. Aims: To characterize how the software industry professionals in Uruguay understand, perceive, and adopt technical debt management (TDM) activities. Method: To replicate a Brazilian survey with the Uruguayan software industry and compare their findings. Results: From 259 respondents, many indicated any awareness of the TD concept due to the faced difficult to realize how to associate such a concept with actual software issues. Therefore, it is possible to observe a considerable variability in the importance of TDM among the respondents. However, a small part of the respondents declares to carry out TDM activities in their organizations. A list of software technologies declared as used by practitioners was produced and can be useful to support TDM activities. Conclusions: The TD concept and its management are not common yet in Uruguay. There are indications of TD unawareness and difficulties in the conduction of some TDM activities considered as very important by the practitioners. There is a need for more effort aiming to disseminate the TD knowledge and to provide software technologies to support the adoption of TDM in Uruguay. It is likely other software engineering communities face similar issues. Therefore, further investigations in these communities can be of interest.

In experiments with crossover design subjects apply more than one treatment. Crossover designs are widespread in software engineering experimentation: they require fewer subjects and control the variability among subjects. However, some researchers disapprove of crossover designs. The main criticisms are: the carryover threat and its troublesome analysis. Carryover is the persistence of the effect of one treatment when another treatment is applied later. It may invalidate the results of an experiment. Additionally, crossover designs are often not properly designed and/or analysed, limiting the validity of the results. In this paper, we aim to make SE researchers aware of the perils of crossover experiments and provide risk avoidance good practices. We study how another discipline (medicine) runs crossover experiments. We review the SE literature and discuss which good practices tend not to be adhered to, giving advice on how they should be applied in SE experiments. We illustrate the concepts discussed analysing a crossover experiment that we have run. We conclude that crossover experiments can yield valid results, provided they are properly designed and analysed, and that, if correctly addressed, carryover is no worse than other validity threats.