Monorepos Lead To Bad Developer Culture

Hear me out.

This might seem like somewhat of a stretch, but hear me out.

I have been exposed to some fairly large monorepos in the past, in medium to large sized companies, where hundreds of developers across many teams shared a single monorepo.

First a few definitions to set the scene.

What is a monorepo, multirepo?

A monorepo is a version controlled code repository that contains many projects. Although these projects may be related, they are usually logically separate and maintained by different teams.

The opposite of a monorepo is a multirepo, where each project is stored in a completely separate, versioned repository. Multirepos come naturally - most of us do it when we start a new project.

At first glance, choosing between monorepos and multirepos may not seem like a big deal, but it's a decision that will greatly affect your company's development workflow.

Pros

There are some pros and cons that are worth discussing. Let's start with the positive side:

• Visibility: All code is kept in the same place. It may seem obvious, but having a single place to look for all code does make it a lot easier to find other team's code.
• Shared timeline: Breaking changes to APIs or shared libraries are exposed immediately, forcing disparate teams to communicate and join forces ahead of time. Everyone has an interest in keeping up with the changes.
• Unified CI/CD: You can use the same CI and CD process for every project in the repo.

Cons

The cons on the other hand are really significant. They are mostly of a different nature. While the pros are of the nature, where they make the technical issues slightly easier. The cons, on the other hand, are more of the soft human nature - the kind that lead to multiple teams with diverging views of what "good" code quality or "good" ways of working looks like.

• Bad performance: Monorepos are difficult to scale up. Commands like git blame may take unreasonably long times.
• Broken main/master: A broken main branch affects everyone working in the monorepo. This usually leads to very defensive teams where finger pointing and blame game becomes more important than productivity.
• Learning curve: The learning curve for new developers is steeper if the repository spans many tightly-coupled projects. Instead of having to learn about one domain to update one part of the code - everyone has to learn about all domains to update one part of the code. Additionally, tools like nx which are bloated and has significantly more complex configuration than a simple package.json file.
• Large volumes of data: Monorepos can reach unmanageable data volumes and commits per day.
• Ownership: Maintaining ownership of projects and especially libraries is more challenging, as tight coupling means that several teams share libraries and code that is owned by everyone is effectively owned by noone.
• Code reviews: Notifications can get very noisy. Github, for instance, has limited notifications settings that are not best suited for a snow slide of pull requests and code reviews.
• Codifying everything: As shared rules for what "good" looks like starts to take hold, every decision will inevitably be codified - leading to less cross team coorporation and more local micro-kings asserting their way of working on other teams. Teams may spend their time arguing over linter rules instead of producing value for actual customers.

Cultural effects of monorepos in large organisations

As a engineering organisation, you will need to decide if you believe in team autonomy. Do you want your individual teams to be able to really take ownership of their tools and processes? Do you value uniformity over team independence?

Having seen what an organisation where local fiefdoms rule and fear of repercussions impacts all ways of working, to the extend where innovation all but grinds to a complete halt, I hope that I will forever be free of the cultural side effects of monorepos now and in the future.

Appropriate use of monorepos

I actually use monorepos in some of my side projects that I work on alone. I have even seen them sort-of work in tiny teams that had multiple sub-projects as part of a single service.

If you choose simple tools (like turborepo) over complex ones (like nx), and you don't have to scale across multiple teams, then a monorepo might be appropriate for you.

So, ironically, the best choice for a small team might be what is generally accepted as the answer for large organisations, and the best choice for large organisations may be what is generally accepted as the answer for small organisations.