[taeric]

Google being a giant monorepo is almost certainly at play here. Maintenance costs are always high on products. But upgrades and constant progress on underlying technology is, itself, often a large part of the need for maintenance.

Please don't take this as an argument against monorepo. It is a discussion point there, but even if you view this as largely negative, I assert a lot of these negatives come with the size of Google.

[msm_]

Interesting, i've always considered monorepo to be a maintainability win. Your code doesn't rot (as much) because it's constantly rebuilt and tested. When someone improves some downstream code (for example makes some code faster or safer) you get the benefits immediately. And most importantly - you can do huge interface-breaking refactorings on the whole codebase at once, without versioning dance. For example you can remove a parameter from some function in the library and make sure all clients still work, atomically. I think this is a huge maintainability win - as long as you actually want to maintain something and not let it rot.

But really, do you have a choice? Sooner or later someone finds a security bug in the code and you actually have to dig out the code and deploy an update.

[taeric]

The catch, of course, is a lot of the "migrate to newer versions" of some libraries brings in new features. These new features can be the source of new security concerns. Especially when added with a lot of the changes requiring some reworking on how things are used for the migration.

This would be akin to trying to move a car to a system that shuts off during stops. Totally doable, but requires a massive change in how reliant passive systems are on the serpentine belt/alternator for power.

[digging]

I'm not against monorepos but this seems like such an obvious case of one being inappropriate. I'm very curious why it's important to G to maintain their products in a colossal monorepo. Obviously they have very smart people working on these issues, but they're also not infallible.