week 16 - Monolithic repo at Google, when your code starts to smell and definition of done in agile software development projects
Monolithic source code repositories (repos) are used by several large tech companies, but little is known about their advantages or disadvantages compared to multiple per-project repos. This paper investigates the relative tradeoffs by utilizing a mixed-methods approach. Our primary contribution is a survey of engineers who have experience with both monolithic repos and multiple, per-project repos. This paper also backs up the claims made by these engineers with a large-scale analysis of developer tool logs. Our study finds that the visibility of the codebase is a significant advantage of a monolithic repo: it enables engineers to discover APIs to reuse, find examples for using an API, and automatically have dependent code updated as an API migrates to a new version. Engineers also appreciate the centralization of dependency management in the repo. In contrast, multiple-repository (multi-repo) systems afford engineers more flexibility to select their own toolchains and provide significant access control and stability benefits. In both cases, the related tooling is also a significant factor; engineers favor particular tools and are drawn to repo management systems that support their desired toolchain.
This article provides insight into two simple and common problems when teaching XP: the “Bootstrap” and “Split Personality” antipractices. Bootstrap describes how teams have difficulties starting a project with little or no code base. Split Personality describes difficulties experienced when one assumes both the Coach and Customer roles. We present these organizational antipatterns as antipractices we have identified while teaching XP in different contexts. We discuss simple solutions to the antipatterns based on reflections from these experiences and describe concrete situations where they were effective.
领英推荐
Technical debt is a metaphor introduced by Cunningham to indicate “not quite right code which we postpone making it right”. One noticeable symptom of technical debt is represented by code smells, defined as symptoms of poor design and implementation choices. Previous studies showed the negative impact of code smells on the comprehensibility and maintainability of code. While the repercussions of smells on code quality have been empirically assessed, there is still only anecdotal evidence on when and why bad smells are introduced, what is their survivability, and how they are removed by developers. To empirically corroborate such anecdotal evidence, we conducted a large empirical study over the change history of 200 open source projects. This study required the development of a strategy to identify smell-introducing commits, the mining of over half a million of commits, and the manual analysis and classification of over 10K of them. Our findings mostly contradict common wisdom, showing that most of the smell instances are introduced when an artifact is created and not as a result of its evolution. At the same time, 80 percent of smells survive in the system. Also, among the 20 percent of removed instances, only 9 percent are removed as a direct consequence of refactoring operations.
Background: Definition of Done (DoD) is a Scrum practice that consists of a simple list of criteria that adds verifiable or demonstrable value to the product. It is one of the most popular agile practices and assures a balance between short-term delivery of features and long-term product quality, but little is known of its actual use in Agile teams. Objective: To identify possible gaps in the literature and define a starting point to define DoD for practitioners through the identification and synthesis of the DoD criteria used in agile projects as presented in the scientific literature. Method: We applied a Systematic Literature Review of studies published up to (and including) 2016 through database search and backward and forward snowballing. Results: In total, we evaluated 2326 papers, of which 8 included DoD criteria used in agile projects. We identified that some studies presented up to 4 levels of DoD, which include story, sprint, release or project. We identified 62 done criteria, which are related to software verification and validation, deploy, code inspection, test process quality, regulatory compliance, software architecture design, process management, configuration management and non-functional requirements. Conclusion: The main implication for research is a need for more and better empirical studies documenting and evaluating the use of the DoD in agile software development. For the industry, the review provides a map of how DoD is currently being used in the industry and can be used as a starting point to define or compare with their own DoD definition.