3 ms·

I have two main concerns when I see monorepos being used. First, like in other areas, I see companies that want to "google scale" and blindly copy the idea of

• bunderbunder 9y ago
  > I worry about the coupling between unrelated products. I even worry about coupling among related products. I could see monorepos working out well for a company that just does SaaS, and is able to get away with nice things like maintaining a single running version of the app, and continuous delivery. Having mostly worked in companies that do shrinkwrap software or that allow different teams or clients to manage their own upgrade schedule, though, monorepo seems to me like a recipe for a codebase that is horribly resistant to change. Not just in the "big bang upgrades like JUnit4 are awful" ways described above, but also in a, "We never clean up old stuff, because most of the time when we try it breaks a bunch of other teams' code and we just nope out of that whole hassle, so barely-supported code sort of collects continuously, like dead underbrush in a forest that's never allowed to burn, until eventually it all explodes in a horrible conflagration," sort of way. Seeing the list of things that Google keeps in a monorepo, vs things that Google keeps in Git repos, it seems like they might be thinking similarly. They've really only got a precious few products that typically run on non-Google-owned hardware, and apparently the major ones live outside the monorepo.
  • joshuamorton 9y ago
    >They've really only got a precious few products that typically run on non-Google-owned hardware, and apparently the major ones live outside the monorepo. This depends on what you mean. Most/all consumer android applications don't run on google-owned hardware, but are in the monorepo. That said, you're right that the whole "keep things up to date" thing is important. That's where tools like rosie and even bots come in.
  • smallnamespace 9y ago
    The dynamics actually played out very differently at Google. Because it was a monorepo with automated testing, if you didn't want other teams to break you when they change the dependencies, then you had better have a robust test suite. Breaking changes would then lead to a discussion with your team, rather than your fruitlessly trying to binary search to find the commit that broke you. Over time, the culture at Google became that all teams need to write tests at the unit, functional, and (usually) integration level.
  • rifung 9y ago
    > Seeing the list of things that Google keeps in a monorepo, vs things that Google keeps in Git repos, it seems like they might be thinking similarly. They've really only got a precious few products that typically run on non-Google-owned hardware, and apparently the major ones live outside the monorepo. I always thought it was more that the things which take open source contributions are hosted in Git while the internal things would be hosted in Google3.
• cletus 9y ago
  First, I agree with you about companies worrying prematurely or unnecessarily about “google scale”. You saw this a lot in the NoSQL hype days. You can go pretty darn far with even a single MySQL instance. Second, source level dependencies bs binary level dependencies has s a choice and a commitment. Even at large companies release schedules can really hinder you. I didn’t hear about the JUnit issue but I can believe it. With code bases this large you have to get really good at static analysis (dynamic languages are your enemy here), tooling for refactoring and just general hygiene of the code baee.
• argonaut 9y ago
  For the first concern you have things totally flipped. A monorepo actually seems best suited for a small company, with a small codebase and a small set of services. If anything, the stage of company where it makes most sense to have many small repos is when you have a large company with multiple unrelated products, services, teams, etc.
  • bonzini 9y ago
    You're right that monorepos are just fine for small company. The problem is that at some point they don't scale without code review discipline and sophisticated tooling (such as Google's); thus there is a bottleneck where it becomes harder and harder to scale it until you get your tools right.
    • argonaut 9y ago
      Yes, but that point is probably when you have hundreds of engineers, at which point you can afford to have (and probably will already have) a few engineers working on internal tooling.
• user5994461 9y ago
  >>> First, like in other areas, I see companies that want to "google scale" and blindly copy the idea of monorepos but without the requisite tooling teams or cloud computing background / infrastructure that makes this possible. Mono repo will work fine for most small and medium companies without issue, even on top of git. The need for special tooling and performance issues will only pops up when you have millions upon millions of lines of code.