To Monorepo or not to Monorepo: Which is right for you and your organization?
A lot of articles are out there which discuss the age-old argument of monorepos vs multirepos. TLDR of all these articles — like most choices in engineering (and life?) both approaches have pros and cons. On the one hand, monorepo is often touted as the more efficient and streamlined option. On the other hand, multirepo can offer greater flexibility and granularity. But how can you decide which option is best for your organization?
As with many technical decisions, the path to choose might not be technical at all… in fact it might be dependent on your organization’s unique culture and structure. That’s where Conway’s Law comes in. This law states that “organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations.” This means the design of a system will reflect the organizational structure that produced it. In other words, the way code is organized and structured can be seen as a reflection of your organization’s chart. So when it comes to choosing between monorepo and multirepo architectures, it’s not just a technical decision. It’s a decision that is deeply intertwined with the culture and structure of your organization.
Quick Recap
Before we dive into the implications of Conway’s Law, let’s briefly outline the pros and cons of monorepo and multirepo architectures.
Monorepo architectures have the benefit of providing a unified codebase, which can make it easier to share code across teams and projects. They often make it easier to manage dependencies and ensure consistency across the codebase. Sounds great right? Well, one of the biggest challenges of monorepo architectures is the potential for communication issues. When all teams are working in the same codebase, it becomes very easy for different teams to make changes to shared code to get their features working. This can result in conflicts and difficulties coordinating changes which may slow down development and create unnecessary bottlenecks.
Multirepo architectures have the benefit of providing greater flexibility and granularity. By separating codebases into smaller, more focused repositories, teams can work more independently and avoid stepping on each other’s toes. Often, it can be easier to manage releases and track changes when code is divided into smaller repositories. However, multirepo architectures have their own issues. For example, feedback loops are usually slower in a multirepo; you only get feedback when clients start to upgrade to your latest version.
Also, in a multirepo you need to remember to write an upgrade guide, but if you make a breaking change in a monorepo you have to fix it everywhere or else you can’t build. To be fair, though, this might be more true in theory than in practice:, the person responsible for fixing the breaking change in clients usually is not as familiar with or interested in the client code, leaving behind technical debt for others to handle.
Implications of Conway’s Law
Conway’s law states that the architecture of a software system reflects the communication structure of the organization that produced it. This means that the way teams communicate and collaborate affects the architecture of the system they produce. So, when considering whether to use a monorepo or multirepo architecture, it’s important to consider the communication patterns within your organization.
If your organization has a highly collaborative culture with strong lines of communication between teams (an example might be a startup), a monorepo may be the right choice. In a monorepo, all code is stored in a single repository, which can make it easier for teams to coordinate and manage changes. For example, if different teams are working on different parts of the same project, they can more easily coordinate changes and ensure that everyone is working with the most up-to-date code.
Monorepos also encourages code reuse and reduce duplication of effort. If multiple teams are working on similar or related projects, they can easily share code and avoid duplicating effort. This can save time and reduce the likelihood of bugs being introduced due to code duplication.
For other organizations a multirepo may be a better fit. If your organization values independent teams managing their own products based on their own priorities (for example one team is spending a sprint or two on tech debt and updating dependencies but another has a high-priority business feature). Alternatively, if your organization is more decentralized or has less well-defined lines of communication (an example might be a larger organization with teams in separate offices or even timezones) then a multirepo might work better.
In a multirepo, each project or team has its own repository, which can make it easier for teams to work independently and avoid conflicts. This decentralized approach helps prevent the scenario of “too many cooks in the kitchen”, where multiple teams inadvertently step on each other’s toes or hinder progress due to overlapping changes. While it’s possible to manage this in a monorepo, even with many teams working on the same codebase, opting for a multirepo means there are not even any conflicts to manage.
Multirepos can allow teams to have more control over their own codebases and release cycles. Each team can choose when and how to release their own code, without being dependent on other teams. This can be especially important for teams that are working on projects with different timelines or requirements.
When deciding on whether to adopt a monorepo architecture, it is crucial to consider the specific needs and culture of the organization, as well as the implications of Conway’s Law. A monorepo architecture may be well-suited for organizations that value communication, collaboration, and knowledge sharing, while a multirepo architecture may be a better fit for organizations with a more siloed structure. Additionally, organizations should consider the size of the project and the tooling and infrastructure required to support the chosen architecture. By carefully evaluating these factors, organizations can make an informed decision on which architecture best suits their needs, taking into account the implications of Conway’s Law.
