Paper presentation at ICW'19. Abstract: Product and engineering teams’ speed of producing high-quality results is critical to ensuring enterprise competitiveness. Additionally, one can observe an increase in IT systems complexity driven by the adoption of service-oriented architecture, micro-services, and serverless. Therefore, many large enterprises benefit from a mono-repository for source code management because of the improved team cognition that results from eroding barriers between teams and from influencing enhanced teamwork quality. This paper, first, reviews the characteristics of a multi-repositories structure, a monorepository structure, and a hybrid model. Second, it discusses why some manage source code in a multi-repositories structure, either by choice or because of the organic evolution of large enterprises. Third, it reviews how mono-repositories in large teams, beyond the technical arguments, can drive high efficiency and enhanced product quality through improved team cognition.

1. © 2018 Adobe Systems Incorporated. All Rights Reserved. Adobe Confidential.
The Issue of Monorepo and Polyrepo In Large Enterprises
‹Programming› 2019 / ICW 2019
Nicolas Brousse | Director, SRE

2. © 2018 Adobe Systems Incorporated. All Rights Reserved. Adobe Confidential.
Practical definitions
Monorepo
Use one unique source code repository for multiple projects and their
dependencies.
Polyrepo
Use a source code repository for each project, component, and/or library.
2

3. © 2018 Adobe Systems Incorporated. All Rights Reserved. Adobe Confidential.
A decade of soul-searching
Over the past 10 years, we went through:
|-> Monorepo on SVN
|-> Polyrepo on SVN with use of svn externals
|-> Git polyrepo with Code Review (Gerrit)
|-> Git polyrepo as mono with Code Review and use of submodules (Gerrit)
|-> Git polyrepo with Github Pull Request Model (Bitbucket)
|-> Git monorepo with Github Pull Request Model (Bitbucket)
|-> Git monorepo with Github Pull Request Model (Github Enterprise)
3

4. © 2018 Adobe Systems Incorporated. All Rights Reserved. Adobe Confidential.
Systems are becoming more complex
4
Complexity
Microservices
&
Distributed Systems
Human Cognitive Limit

5. © 2018 Adobe Systems Incorporated. All Rights Reserved. Adobe Confidential.
Remember the Editor War?
5
Image credit: xkcd.com

6. © 2018 Adobe Systems Incorporated. All Rights Reserved. Adobe Confidential.
A repo war?
6
Structure Implementation Notable Adopters
Polyrepo One distinct source code
repository for each component
and library
Amazon, Netflix, Lyft
Monorepo One source code repository for
a whole company or large
project
Google, Facebook, Microsoft,
Uber, Twitter, React, Angular,
Kubernetes
Hybrid Poly-as-Mono Updates are made to a
polyrepo but managed like a
monorepo
Android, Chrome
Hybrid Mono-as-Poly Updates are made into a
monorepo but then split into
read-only polyrepo for build or
distribution purpose
Symphony, Shopsys

7. © 2018 Adobe Systems Incorporated. All Rights Reserved. Adobe Confidential. 7
Monorepo Polyrepo
Customized
Developer
workflows
Unique
Team
Culture
Use one unique source
code repository for
multiple projects and their
dependencies
Single source of truth
Allow atomic changes
simplify large scale
refactoring
Compound System
Use a source code
repository for each
project, component,
and/or library
Independent releases
cycles
Each project may have a
customized workflow
Isolation

8. © 2018 Adobe Systems Incorporated. All Rights Reserved. Adobe Confidential. 8
“with a monolithic source tree it makes sense, and is easier, for the person updating a library to update all affected
dependencies at the same time. The technical debt incurred by dependent systems is paid down immediately as
changes are made.”
Rachel Potvin and Josh Levenberg. 2016. Why Google Stores Billions of Lines of Code in a Single Repository.
Commun. ACM 59, 7 (June 2016), 78–87. https://doi.org/10.1145/2854146
Diamond Dependency Problem

9. © 2018 Adobe Systems Incorporated. All Rights Reserved. Adobe Confidential.
Culture at the center of the issue
 Netflix’s Culture - “freedom and
responsibility” and the “keeper test”
(Polyrepo)
 Google’s Philosophy - "It’s best to do
one thing really, really well” and “Great
just isn’t good enough” (Monorepo)
 Microsoft - ”we needed a culture that
allowed us to constantly refresh and
renew” – Satya Nadella (Move from
polyrepo to monorepo)
9
Source: levels.fyi

10. © 2018 Adobe Systems Incorporated. All Rights Reserved. Adobe Confidential.
 “An important aspect of Google culture that encourages code quality is the
expectation that all code is reviewed before being committed to the repository.”
 “A developer can make a major change touching hundreds or thousands of files
across the repository in a single consistent operation.”
10
Rachel Potvin and Josh Levenberg. 2016. Why Google Stores Billions of Lines of Code in a Single Repository.
Commun. ACM 59, 7 (June 2016), 78–87. https://doi.org/10.1145/2854146

11. © 2018 Adobe Systems Incorporated. All Rights Reserved. Adobe Confidential. 11
Phil Ensor. 1988. Organizational Renewal-Tearing Down the Functional Silos. In AME Study Group on Functional
Organization. AME Target, 4–16.

12. © 2018 Adobe Systems Incorporated. All Rights Reserved. Adobe Confidential. 12
Jun He, Brian S. Butler, and William R. King. 2007. Team Cognition: Development and Evolution in Software
Project Teams. J. of Management Information Systems 24 (2007), 261–292.

13. © 2018 Adobe Systems Incorporated. All Rights Reserved. Adobe Confidential. 13
“Software project teams’ ability to operate as a team arises from who they are
(preexisting team characteristics) and how they interact (team communication).
Team cognition concepts provide potential levers for managers seeking to improve
the performance of these teams. An arbitrary collection of people can, with a great
deal of effort and some luck, accomplish significant goals. However, by forming
team cognition, those individuals can increase their chances of success. The
more we understand about the formation of team cognition, both within software
project teams and in general, the more effective we will be at explaining and
supporting the formation of effective teams.”
Jun He, Brian S. Butler, and William R. King. 2007. Team Cognition: Development and Evolution in Software
Project Teams. J. of Management Information Systems 24 (2007), 261–292.

14. © 2018 Adobe Systems Incorporated. All Rights Reserved. Adobe Confidential.
“In 2014, we operationalized and validated a model of organizational culture
proposed by sociologist Ron Westrum and showed that it drives both software
delivery performance and organizational performance. Over the last few years
we’ve found a number of management and technical capabilities that influence
culture, showing that you can change culture by changing the way work is done
in your organization.”
“We find that technical and management practices shape culture and that
culture in turn helps to improve performance outcomes.“
14
DORA. 2018. Accelerate: State of DevOps Strategies for a New Economy.

15. © 2018 Adobe Systems Incorporated. All Rights Reserved. Adobe Confidential.
Paper Conclusion
Technical arguments between one model and another are not a clear-cut.
“A monorepo facilitates cultural change and enables a holistic team cognition that
ensures high quality work and improves communication, while preserving necessary
autonomy.”
---
Can the decisioning process of choosing a source code repository structure be
more data driven and scientific?
Is there an opportunity for architecture / design patterns that could benefit
practitioners?15