Accountability is an innate part of social systems. It maintains stability and ensures positive pressure on individuals’ decision-making. As actors in a social system, software developers are accountable to their team and organization for their decisions. However, the drivers of accountability and how it changes behavior in software development are less understood. In this study, we look at how the social aspects of code review affect software engineers’ sense of accountability for code quality. Since Software Engineering (SE) is increasingly involving Large Language Models (LLM) assistance, we also evaluate the impact on accountability when introducing LLM-assisted code reviews. We carried out a two-phased sequential qualitative study ( \(\textbf{interviews}\rightarrow\textbf{focus groups}\) ). In Phase I (16 interviews), we sought to investigate the intrinsic drivers of software engineers influencing their sense of accountability for code quality, relying on self-reported claims. In Phase II, we tested these traits in a more natural setting by simulating traditional peer-led reviews with focus groups and then LLM-assisted review sessions. We found that there are four key intrinsic drivers of accountability for code quality: personal standards , professional integrity , pride in code quality , and maintaining one’s reputation . In a traditional peer-led review, we observed a transition from individual to collective accountability when code reviews are initiated. We also found that the introduction of LLM-assisted reviews disrupts this accountability process, challenging the reciprocity of accountability taking place in peer-led evaluations, i.e., one cannot be accountable to an LLM. Our findings imply that the introduction of AI into SE must preserve social integrity and collective accountability mechanisms.

Abstract Context Free and Open Source Software (FOSS) communities’ ability to stay viable and productive over time is pivotal for society as they maintain the building blocks that digital infrastructure, products, and services depend on. Sustainability may, however, be characterized from multiple aspects, and less is known how these aspects interplay and impact community outputs, and software quality specifically. Objective This study, therefore, aims to empirically explore how the different aspects of FOSS sustainability impact software quality. Method 16 sustainability metrics across four categories were sampled and applied to a set of 217 OSS projects sourced from the Apache Software Foundation Incubator program. The impact of a decline in the sustainability metrics was analyzed against eight software quality metrics using Bayesian data analysis, which incorporates probability distributions to represent the regression coefficients and intercepts. Results Findings suggest that selected sustainability metrics do not significantly affect defect density or code coverage. However, a positive impact of community age was observed on specific code quality metrics, such as risk complexity, number of very large files, and code duplication percentage. Interestingly, findings show that even when communities are experiencing sustainability, certain code quality metrics are negatively impacted. Conclusion Findings imply that code quality practices are not consistently linked to sustainability, and defect management and prevention may be prioritized over the former. Results suggest that growth, resulting in a more complex and large codebase, combined with a probable lack of understanding of code quality standards, may explain the degradation in certain aspects of code quality.

Abstract Psychological safety continues to pique the interest of scholars in a variety of disciplines of study. Recent research indicates that psychological safety fosters knowledge sharing and norm clarity and complements agile values. Although software quality remains a concern in the software industry, academics have yet to investigate whether and how psychologically safe teams provide superior results. In this study, we explore how psychological safety influences agile teams’ quality-related behaviors aimed at enhancing software quality. To widen the empirical coverage and evaluate the results, we chose a two-phase mixed-methods research design with an exploratory qualitative phase (20 interviews) followed by a quantitative phase (survey study, N = 423). Our findings show that, when psychological safety is established in agile software teams, it induces enablers of a social nature that advance the teams’ ability to pursue software quality. For example, admitting mistakes and taking initiatives equally help teams learn and invest their learning in their future decisions related to software quality. Past mistakes become points of reference for avoiding them in the future. Individuals become more willing to take initiatives aimed at enhancing quality practices and mitigating software quality issues. We contribute to our endeavor to understand the circumstances that promote software quality. Psychological safety requires organizations, their management, agile teams, and individuals to maintain and propagate safety principles. Our results also suggest that technological tools and procedures can be utilized alongside social strategies to promote software quality.

Software bots fulfill an important role in collective software development, and their adoption by developers promises increased productivity. Past research has identified that bots that communicate too often can irritate developers, which affects the utility of the bot. However, it is not clear what other properties of human-bot collaboration affect developers' preferences, or what impact these properties might have. The main idea of this paper is to explore characteristics affecting developer preferences for interactions between humans and bots, in the context of GitHub pull requests. We carried out an exploratory sequential study with interviews and a subsequent vignette-based survey. We find developers generally prefer bots that are personable but show little autonomy, however, more experienced developers tend to prefer more autonomous bots. Based on this empirical evidence, we recommend bot developers increase configuration options for bots so that individual developers and projects can configure bots to best align with their own preferences and project cultures.

Psychological safety continues to inspire researchers’ curiosity in various fields of study. It has been shown to enhance teams’ performance, efficiency, and learning, among other corollaries. Researchers are stretching the boundaries of these early findings to identify further effects of psychological safety. Recent work shows that psychological safety promotes knowledge sharing, norm clarity, and complements agile values. Studies show that psychological safety enhance agile values and practices, and some practitioners went as far as to claim “agile doesn’t work without psychological safety.” Yet, researchers have not explored its antecedents. In this study, we sought to understand how psychological safety materializes in agile software development teams. We opted for a two-phase mixed-methods study; an exploratory qualitative phase (18 interviews) followed by a quantitative phase (survey study, N = 365) to broaden the empirical coverage and test phase one’s findings. Our findings show that psychological safety is established in agile software teams when individuals, the team, and the leadership adopt and promote strategies conducive to promoting a psychologically safe workplace. While openness and no blame towards team members are the “butter and bread” of psychological safety, collective-decision making within the team and the leadership ownership remain the pillars of a psychologically safe workplace. Conversely, team autonomy, technical practices providing a safety net and slack time were not found to promote psychological safety. To institutionalize psychological safety in agile software teams, individuals, teams, and the leadership should consolidate their effort to adopt no blame, openness, collective decision-making in the team, and assuming the ownership of promoting a psychologically safe workplace.

Technical excellence is a nebulous term in agile software development. This vagueness is risky because it may lead to misunderstandings and to agile implementations that may overlook a key principle of agile development. This study investigates how agile practitioners interpret the concept of technical excellence brought up in Principle 9 of the Agile manifesto. Moreover, we investigate how agile practitioners put the concept into practice and what conditions facilitate putting technical excellence into practice. We conducted semi-structured interviews with twenty agile practitioners, coded the data inductively, and performed two sessions to validate the emerging findings. We find that technical excellence is first and foremost a mindset that is underpinned by continuous attention to sustainable code, continuous learning, and teamwork. Fostering technical excellence requires the adoption of design and development practices, such as continuous architecting, and is supported by continuous learning. We also identify three enabling conditions for technical excellence: Leadership support, customer buy-in, and psychological safety. These enablers provide teams with leeway to nurture their pursuit of technical excellence. Our findings highlight the key role of people-based strategies in promoting technical excellence in agile software development. They show that the attainment of technical excellence does not only involve technical practices. On the contrary, it relies on social and organizational support and, most importantly, a mindset.

Pull requests facilitate inclusion and improvement of contributions in distributed software projects, especially in open source communities. An author makes a pull request to present a contribution as a candidate for inclusion in a code base. The request is inspected by maintainers and reviewers. The initiated process of review and collaborative improvement can be loaded with debates, opinions, and emotions. It heavily influences the atmosphere in the community. It can demotivate and detract contributors or it can fail to guard the code quality. Both problems put the existence of a community at risk. This mixed methods study aims to elucidate the mechanisms of evaluating pull requests in diverse open source software communities from the perspectives of developers and maintainers. We interviewed 30 participants from five different communities and conducted a survey with N=387 respondents. The data shows that acceptance of contributions in open source depends not only on technical criteria, but also significantly on social and strategic aspects. As a result, we identify three governance styles for pull requests: (1) protective, (2) equitable, and (3) lenient. While the protective style values trustworthiness and reliability of the contributor, the lenient style believes in creating a positive and welcoming environment where contributors are mentored to evolve contributions until the community standards are met. Each of the governance styles safeguards the quality of the project code in different ways. We hope that this material will help researchers and community managers to obtain a more nuanced view on the peculiarities of different communities and the strengths and weakness of their pull requests evaluation process.

“Technical excellence” is a nebulous term in agile software development. This vagueness is risky, as it creates a gap in the understanding of agile that may have consequences on how software development practitioners operate. Technical excellence is the only reference to quality in the agile manifesto. Hence, it is fundamental to understand how agile software development practitioners both interpret and implement it. We conducted interviews with twenty agile practitioners about their understanding of the term “technical excellence” and how they approach the task of fostering it. To validate the findings, two focus group meetings were conducted after the interviews and the analysis of the data were completed. We found that the configuration of technical excellence is made of four traits: (1) software craftsmanship; (2) software quality (3) mindset for excellence; and (4) consistency with good software engineering practices. Fostering technical excellence is a continuous endeavor. Further, we identified three key principles that were commonly cited as essential to implementing technical excellence, namely: 1) continuous learning; 2) continuous improvement; and 3) control of excellence. Based on our findings, we present several recommendations for software development teams seeking to better realize the goal of technical excellence in their agile implementation.

Pull requests are a method to facilitate review and management of contribution in distributed software development. Software developers author commits, and present them in a pull request to be inspected by maintainers and reviewers. The success and sustainability of communities depends on ongoing contributions, but rejections decrease motivation of contributors. We carried out a a qualitative study to understand the mechanisms of evaluating PRs in open source software (FOSS) communities from developers and maintainers perspective. We interviewed 30 participants from five different FOSS communities. The data shows that acceptance of contributions depends not only on technical criteria, but also significantly on social and strategic aspects. This paper identifies three PR governance styles found in the studied communities: (1) protective, (2) equitable and (3) lenient. Each one of these styles has its particularities. While the protective style values trustworthiness and reliability of the contributor, the lenient style believes in creating a positive and welcoming environment where contributors are mentored to evolve contributions until they meet the community standards. Despite the differences, these governance styles have a commonality, they all safeguard the quality of the software.

Background: The adoption of Free/Libre and Open Source Software (FOSS) by institutions is significantly increasing, and so is the affiliated participation (the participation of industry engineers in open source communities as part of their jobs). Aims: This study is an investigation into affiliated participation in FOSS communities. So far, little is known about the affiliated participation and the forces that influence it, even though the FOSS innovation model is increasingly becoming a serious contender for the private investment model in many sectors. Method: We present a qualitative inquiry into affiliated participation in the Robot Operating System (ROS) and Linux Kernel communities, using twenty-one in-depth interviews and participatory observation data from twenty-nine community events. Results: Our results show that affiliated participation in these communities is constrained by several barriers: objections of senior management, protection of the company's image, protection of intellectual property, undefined processes and policies, the high cost of participation, and unfamiliarity with the FOSS system. Conclusions: These barriers should be addressed in any organization considering using FOSS as a significant acquisition, distribution, and development strategy.

Open source software communities have demonstrated that they can produce high quality results. The overall success of peer code review, commonly used in open source projects, has likely contributed strongly to this success. Code review is an emotionally loaded practice, with public exposure of reputation and ample opportunities for conflict. We set off to ask why code review works for open source communities, despite this inherent challenge. We interviewed 21 open source contributors from four communities and participated in meetings of ROS community devoted to implementation of the code review process. It appears that the hacker ethic is a key reason behind the success of code review in FOSS communities. It is built around the ethic of passion and the ethic of caring. Furthermore, we observed that tasks of code review are performed with strong intrinsic motivation, supported by many non-material extrinsic motivation mechanisms, such as desire to learn, to grow reputation, or to improve one's positioning on the job market. In the paper, we describe the study design, analyze the collected data and formulate 20 proposals for how what we know about hacker ethics and human and social aspects of code review, could be exploited to improve the effectiveness of the practice in software projects.