[klodolph]

Multirepo also comes with cost overhead. I think people talk about it somewhat less. I’ve worked at multirepo and monorepo places, both, before. My current company has a multirepo setup and it sure seems like it comes with plenty of tooling to fetch dependencies. That tooling has to be supported by FTEs.

[aylmao]

+1. I'd go as far to say that multi-repo probably needs as much, if not more effort to properly keep functioning, but all that effort is better "hidden" so people assume monorepos are more work.

With a monorepo, it's common to have a team focused on tooling and maintaining the monorepo. The structure of the codebase lends itself to that

With a multirepo codebase, it's usually up tu different teams to do the work associated with "multirepo issues"— orchestrate releases, handle dependencies, dev environment setup, etc. So all that effort just kinda gets "tucked away" as overhead that each team assumes, and isn't quite as visible

[codethief]

I couldn't agree more! At the company I currently work for I have seen this phenomenon time and again.

[hibikir]

Internally, they definitely do. I worked at Stripe's monorepo many years ago, and I am working at a larger company with massive amounts of repos. The difference in pain has little to do with mono v multi, but with the capabilities of your tooling team.

If there's anything I'd say to low-level execs, the kind that end up with a few hundred developers under them, it's that mis-sizing the tooling team, in one way or the other, comes with total productivity penalties that will appear invisible, but will make everything expensive. Understanding how much of a developer's day is toil is very important, but few really try to figure that out.