Locating Community Smells in Software Development Processes Using Higher-Order Network Centralities

Community smells are negative patterns in software development teams' interactions that impede their ability to successfully create software. Examples are team members working in isolation, lack of communication and collaboration across departments or sub-teams, or areas of the codebase where only a few team members can work on. Current approaches aim to detect community smells by analysing static network representations of software teams' interaction structures. In doing so, they are insufficient to locate community smells within development processes. Extending beyond the capabilities of traditional social network analysis, we show that higher-order network models provide a robust means of revealing such hidden patterns and complex relationships. To this end, we develop a set of centrality measures based on the MOGen higher-order network model and show their effectiveness in predicting influential nodes using five empirical datasets. We then employ these measures for a comprehensive analysis of a product team at the German IT security company genua GmbH, showcasing our method's success in identifying and locating community smells. Specifically, we uncover critical community smells in two areas of the team's development process. Semi-structured interviews with five team members validate our findings: while the team was aware of one community smell and employed measures to address it, it was not aware of the second. This highlights the potential of our approach as a robust tool for identifying and addressing community smells in software development teams. More generally, our work contributes to the social network analysis field with a powerful set of higher-order network centralities that effectively capture community dynamics and indirect relationships.Comment: 48 pages, 19 figures, 4 tables; accepted at Social Network Analysis and Mining (SNAM

Mitigating Turnover with Code Review Recommendation: Balancing Expertise, Workload, and Knowledge Distribution

Developer turnover is inevitable on software projects and leads to knowledge loss, a reduction in productivity, and an increase in defects. Mitigation strategies to deal with turnover tend to disrupt and increase workloads for developers. In this work, we suggest that through code review recommendation we can distribute knowledge and mitigate turnover with minimal impact on the development process. We evaluate review recommenders in the context of ensuring expertise during review, Expertise, reducing the review workload of the core team, CoreWorkload, and reducing the Files at Risk to turnover, FaR. We find that prior work that assigns reviewers based on file ownership concentrates knowledge on a small group of core developers increasing risk of knowledge loss from turnover by up to 65%. We propose learning and retention aware review recommenders that when combined are effective at reducing the risk of turnover by -29% but they unacceptably reduce the overall expertise during reviews by -26%. We develop the Sophia recommender that suggest experts when none of the files under review are hoarded by developers but distributes knowledge when files are at risk. In this way, we are able to simultaneously increase expertise during review with a ΔExpertise of 6%, with a negligible impact on workload of ΔCoreWorkload of 0.09%, and reduce the files at risk by ΔFaR -28%. Sophia is integrated into GitHub pull requests allowing developers to select an appropriate expert or “learner” based on the context of the review. We release the Sophia bot as well as the code and data for replication purposes

The impact of knowledge loss on software projects: turnover, customer found defects, and dormant files

The success of a software project is dependent on the expertise and knowledge of its developers. In this dissertation, we use empirical studies to develop an understanding of the impact of knowledge loss on software projects. First, we studied the damage done to projects from turnover, the susceptibility of the project to future turnover, and the suggestion of potential successors to assume abandoned files. Based on the project vulnerability to turnover, project leaders can induce key developers to stay with the project and to mitigate files abandonment. Second, we did an empirical research on the impact of turnover on the quality of a software project. Third, we performed an examination of the impact of inactive files (dormant files). Our findings on the first research topic showed that the greater the spread of knowledge the less likely a project is to be affected by turnover. Moreover, we found that knowledgeable developers, rather than newcomers, take over abandoned code. In our second study, we observed an unexpected result that in the Chrome web-browser project, the number of developers who leave and join both decreased the number of post-release defects. We discuss this unexpected result. The third study on dormant files, i.e. inactive files, contrasted a legacy system with a popular system. We found that for a legacy system, the developers that take on dormant files were experienced developers

On History-Aware Multi-Activity Expertise Models

Durant l’évolution d’un projet de logiciel, les contributions individuelles d’un developeur present dans le projet vont lentement se faire remplacer par les contributions d’autre dévelopeurs. Ceci engendrera l’érosion de l’empreinte des contributions de ce developeur. Bien que les connaissances de ce dévelopeur n’ont pas disparu du jour au lendemain, pour une personne externe au projet, l’expertise de ce developeur est devenue invisible. Grace à une étude empirique sur une periode de 5 années de developement de Linux, nous étudions le phénomène de l’érosion de l’expertise en créant un modèle bidimentionnel. La première dimention de notre modèle prend en compte les différentes activités entreprises par les membres de la communauté de développement de Linux, comme les contributions en termes de code, les contributions aux revues de code soumit par d’autre dévelopeurs, ou encore la soumission de code d’autres dévelopeurs en amont. La deuxiéme dimention de notre modèle prend en compte l’historique des contributions citées plus haut pour chaque dévelopeurs. En applicant ce modèle, nous decouvrons que, bien que les empreintes de contributions de certain dévelopeurs diminuent avec le temps, leurs expertise survit grace à leurs implications dans les divereses activités mentionées plus haut.----------ABSTRACT: As software evolves, a maintainer’s contributions will gradually vanish as they are being replaced by other developers’ code, resulting in a slow erosion of the maintainer’s footprint in the software project. Even though this maintainer’s knowledge of the file did not disappear overnight, to outsiders, the maintainer and her expertise have become invisible. Through an empirical study on 5 years of Linux development history, this paper analyses this phenomenon of expertise erosion by building a 2-dimensional model of maintainer expertise involving a range of maintainer activity data on more than one release. Using these models, we found that although many Linux maintainers’ own coding footprint has regressed over time, their expertise is perpetuated through involvement in other development activities such as patch reviews and committing upstream on behalf of other developers. Considering such activities over time further improves recommendation models

On the Difficulty of Computing the Truck Factor

In spite of the potential relevance for managers and even though the Truck Factor definition is well-known in the “agile world” for many years, shared and validated measurements, algorithms, tools, thresholds and empirical studies on this topic are still lacking. In this paper, we explore the situation implementing the only approach proposed in literature able to compute the Truck Factor. Then, using our tool, we conduct an exploratory study with 37 open source projects for discovering limitations and drawbacks that could prevent its usage. Lessons learnt from the execution of the exploratory study and open issues are drawn at the end of this work. The most important lesson that we have learnt is that more research is needed to render the notion of Truck Factor operative and usable

On the Difficulty of Computing the Truck Factor

In spite of the potential relevance for managers and even though the Truck Factor definition is well-known in the "agile world" for many years, shared and validated measurements, algorithms, tools, thresholds and empirical studies on this topic are still lacking. In this paper, we explore the situation implementing the only approach proposed in literature able to compute the Truck Factor. Then, using our tool, we conduct an exploratory study with 37 open source projects for discovering limitations and drawbacks that could prevent its usage. Lessons learnt from the execution of the exploratory study and open issues are drawn at the end of this work. The most important lesson that we have learnt is that more research is needed to render the notion of Truck Factor operative and usabl