4 ms·

> 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 comp

> 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.

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.