We’ll Never Know Whether Monorepos Are Better

Even switching sides can’t tell you which side is better.

Dan Fabulich is a Principal Engineer at Redfin. (We’re hiring!)

Years ago, at my first job in the software industry, we ran our company off a single “monolithic” code repository (a “monorepo”).

A small but dedicated group of engineers at the company believed that, as our team grew, we would need to move away from a monorepo to a “multirepo” model, splitting the code up into smaller projects. Each of these would have its own repository and produce released versions (1.0, 1.1, 2.0, etc.) for dependent projects to consume.

Most of the org seemed to express no strong opinion on this, but a subset of our engineers was opposed to the change. The reactionaries believed that monorepo was actually better than multirepo, that the imagined “benefits” of multirepo were overstated and unmeasurable, and that the disadvantages of multirepo were wildly underestimated.

I recall sitting in on very contentious meetings about this. It surprised me, at the time, how hard it was for either side to convince the other. It had the feeling of religious argument, rather than technical argument.

The biggest surprises were yet to come.

The multirepo camp “won” the argument, and we did convert our monorepo to a multirepo. Our code base consisted of multiple compiled languages, so we weren’t able to use any of the standard open-source dependency management tools out there. Most of these were intended to use with one particular language (e.g. Java only, or Perl only, or C# only), so we rolled our own.

Rolling our own dependency-management tooling took a small team of engineers (including me) more than a year of very hard work, and there were problems. There was a month or so when the build was down for days at a time. But eventually we put out the fires and the company got back to work.

About six months after the project was declared “done” (but there was always more to do, more improvements to make to our homegrown dependency management solution), we had a retrospective meeting. The same engineers who had taken sides, for and against the project, were again assembled to discuss how it went.

One of the main opponents went first.

“Thank goodness we’re finally having this retrospective,” he said. “I think we can all see that this experiment has been a colossal failure and that it’s time for us to change course and roll back to monorepo.”

“What do you mean?” one of the main multirepo advocates replied. “This was one of the best decisions we’ve ever made!”

This really shocked me. We had access to all of the data you could possibly want to evaluate the decision. The same engineers working with the same codebase had seen what it was like in the monorepo model and the multirepo model. We knew exactly how much it had actually cost to switch. We had lived with the advantages and disadvantages of both models. But still we couldn’t come to an agreement.

(Even the “no opinion” group mostly remained unchanged. A few people switched from “no opinion” to one side or the other, and a few people from each side switched to “no opinion,” but it wasn’t a movement.)

That retrospective taught me to be humble in my ambitions to “improve” engineering productivity. There’s no way to measure productivity in software, so there’s no way to know whether controversial, expensive “productivity enhancing” projects actually deliver on their promise, even in hindsight.

Today, when asking myself whether to work on wide-reaching infrastructure projects, I ask myself:

Is this change obviously an improvement?

If I think I’m right, but I can’t get a supermajority of the engineering team to agree, I don’t do it.

I work on the Platforms team at Redfin, a team dedicated to supporting the rest of the engineering team. There’s tons of demand for our services, zillions of projects we could work on that are guaranteed to pay off for the entire team. With a backlog like ours, we can afford to dedicate all of our attention to projects that everyone will love, and deprioritize projects that we haven’t finished arguing about yet.

Discussion on Hacker News
Discussion on Reddit

P.S. Redfin is hiring.