DevOps and continuous delivery have impacted the organizational structures of development and infrastructure groups in software-producing organizations. Our research aims at revealing the different options adopted by the software industry to organize such groups, understanding why different organizations adopt distinct structures, and discovering how organizations handle the drawbacks of each structure. We interviewed 68 carefully-selected IT professionals, 45 working in Brazil, 10 in the USA, 8 in Europe, 1 in Canada, and 4 in globally distributed teams. By analyzing these conversations through a Grounded Theory process, we identified conditions, causes, reasons to avoid, consequences, and contingencies related to each discovered structure (segregated departments, collaborative departments, API-mediated departments, and single department). In this way, we offer a theory to explain organizational structures for development and infrastructure professionals. This theory can support practitioners and researchers in comprehending and discussing the DevOps phenomenon and its related issues, and also provides valuable input to practitioners’ decision-making. Published as: L. Leite, N. Lago, C. Melo, F. Kon, and P. Meirelles, ”A theory of organizational structures for development and infrastructure professionals,” in IEEE Transactions on Software Engineering, vol. 49, no. 4, pp. 1898-1911, 1 April 2023, doi: 10.1109/TSE.2022.3199169.

Mechanics are one of the pillars of gameplay, enabled by the underlying implementation of the game. In particular, self-amending mechanics are mechanics that change themselves dynamically and are a common source of duplicate and coupled code because they occur in multiple situations using specific interactions. The Rulebook is an architectural pattern that generalizes how developers deal with these issues, based on a careful research process including a systematic literature review, semi-structured interviews with professional developers, and quasi-experiments. The pattern codifies changes to the game state as “effect” objects, which it matches against a dynamic pool of rules. Each rule may amend, resolve, or chain effects. This design prevents the rest of the game from becoming coupled to the specific interactions of these mechanics while also promoting an extensible and flexible structure for self-amendment. This paper details the Rulebook pattern and presents a case study demonstrating its design process in three different implementations of open-source jam games. Together with the typification of self-amending mechanics, this article formalizes a novel, state-of-the-art toolset for architecting games.

Machine Learning (ML) has grown in popularity in the software industry due to its ability to solve complex problems. Developing ML Systems involves more uncertainty and risk because it requires identifying a business opportunity and managing the source code, data, and trained model. Our research aims to identify the existing practices used in the industry for building ML applications. The goal is to comprehend the orga- nizational complexity of adopting ML Systems. We conducted a Multivocal Literature Review (MLR) and used Grounded Theory (GT) to build a taxonomy with the practices applied to the ML System lifecycle from the industry and academic perspectives. We selected 41 posts from grey literature and 37 papers from scientific repositories. Following a systematic GT protocol, we mapped 91 practices, grouped in 6 core categories related to designing, developing, testing, and deploying ML Systems. The results can help organizations identify the gaps in their current ML processes and practices, and provide a roadmap for improving and optimizing their ML systems. The comprehensive taxonomy of practices developed in this research serves as a valuable tool for managers, practitioners, and researchers in the ML field, providing a clear and organized understanding of the complexity of managing ML systems.

Developers spend significant time locating and fixing bugs, which is often performed manually. Although spectrum-based fault localization (SFL) techniques aim at helping developers to locate faults, they are not yet used in practice. Recent studies have investigated how developers use SFL, presenting different conclusions about their effectiveness and usefulness. We carried out a user study to further enhance the understanding of SFL. We assessed whether SFL improves the developers’ performance and to what extent SFL leads developers to inspect faulty code excerpts. We also investigated the intention of the developers to use SFL and how they interact with SFL. Twenty-six participants performed debugging tasks using real programs, with and without using the Jaguar SFL tool. Using SFL, more developers located and fixed the bugs. SFL also led more developers to inspect the faulty code and locate the faulty method. However, they did not spend less time locating the faults. SFL was well accepted by the participants, who showed intention to use it in their daily activities. Our results indicate that SFL is useful even when the fault is not ranked among the first positions, leading developers to reach faulty code regions and find the bugs.