In a world of warring Monorepo-ists and Microrepo-ists… there is a Middle Path: Polyrepo-ism.

Microrepo-ism ordains that each service composing a total system shall have a repo unto itself. In Microrepo-ist cultures, a single conceptual change to the system requires a coordinated update across multiple repositories. Complex, arduous, and error-prone. Visit https://www.npmjs.com to study Microrepo-ism in the wild.

microrepo.png

In reaction to Microrepo-ism, some companies go full Monorepo. Monorepo-ists decree that there can be only one repo. All code goes into one place, and the total state of the company’s software is indexed by a commit hash into that repo. Atomic changes across interacting services are simple.

monorepo.png

But at what cost?

The Monorepo only grants admission to those commits which pass its battery of tests. These tests grow continuously, as each commit brings its own tests.

Tests aren’t free. They cost time to run. This time is a tax on new development, and you pay that tax regardless of whether your commit has any chance of affecting another component of the system or not.

Imagine if you had to test that your car still started, after fixing a broken window in your house… it makes no sense. These are both things you own, but they are not and cannot possibly interact in a way that would make that a reasonable test to run. This is the cost of Monorepo-ism.

polyrepo.png

Which leads to Polyrepo-ism. Polyrepo-ism factors repositories along natural fault lines between systems. Under Polyrepo-ism, when someone working on a completely-disjoint system breaks the build, it is not your problem.