[arjie]

Why is it so bad? It seems incredibly effective for them and there are very good outcomes:

• no trailing dependencies so you never have to backport fixes, maintain multiple released versions, etc.

• extensive integration testing of libraries since they go live instantly

• forced library developer and library user collaboration

• deployed code is not out of date

What's the problem with only One True Version? All the complaints seem around tooling.

[latch]

Because smaller shops want the benefit of monorepo without paying the cost/discipline it requires. Mono repos without excellent unit tests and integration tests, review processes and various tools, is a disaster. And, in fairness to Google and Facebook, when they talk about the benefits of monorepo, they always mention these costs (it just gets ignored by people: Headline Driven Development)

And I'm sure that the number of companies doing really good integration tests in somewhere in the 1/10000 range (or worse). Every dependency, external provider, internal API, data store, taking into account versioning....it's hard.

I'm a huge believer in automated testing, I've written about it and done it for almost two decades now. My views on it have continuously evolved...and comprehensive and effective integration testing is still a complete mystery to me. The only reason I'd want to work at BigTechCo would be to learn about that specific aspect of software development.

[Chyzwar]

One True Version force you to move whole company in the same pace. Even if you have legacy project you need to keep updating because your dependencies are moving. In the same time if you want to refactor or redesign API you need to wait for all your users and communicate changes since you cannot have beta/alpha release.

I am guessing that in Google people they try to avoid above issue by creating and then depreciating a lot of projects instead having new major release. Older projects will become frozen because too many things depends on them.

This is visible in Google products that take years to change in any way. Gmail/Search are basically the same as long I remember. Given number of engineers in Google it is hard to see any output.

[milesrout]

Well I suppose my statement was a little strong. The Linux kernel is essentially a monorepo: it contains the kernel and many, many dependent projects (drivers/modules). They do what Google claims to do with their monorepo: change all dependent packages at once if they change an internal API.