We’ll Never Know Whether Monorepos Are Better
This makes sense to me where the monorepo-vs-polyrepo argument is concerned — it’s another religious war:
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. 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.
(tags: monorepo productivity dev engineering coding polyrepo)