The solution to the excessive API change problem is to force whoever changes the API to fix all the consumers himself before the change is accepted.
The Linux kernel generally uses this policy for internal APIs for example.
The Linux kernel generally uses this policy for internal APIs for example.
> The solution to the excessive API change problem is to force
> whoever changes the API to fix all the consumers himself
> before the change is accepted.
Does it really make sense to make one developer update those hundred projects? Not only will it take forever for it to get finished (possibly never if there are new consumers of this api coming online frequently), but the developer of the core api may not have any experience in the impacted consumers of this codebase. I think the end result of this policy would be nothing once written ever would get updated, and new apis would just be added all the time (api explosion).
If it was any other way you'd rapidly reach a useless equilibrium where random engineers were demanding that thousands of other engineers fulfill unfunded mandates for what might turn out to be negligible benefits.
Not that it's a silver bullet, but it can make a lot of these cases non-issues.
I mean, it's presumably impossible to have a single computer running a single OS build all of the Google software and run the testing.
Having people unaware of a project's purpose making changes to its code sounds like a nightmare to me.
It's a nice environment to work in. In addition to hastening Noogler onboarding, it also increases employee retention. If you are an expert in your project's codebase but get burned out, you can easily transfer to another project and be almost immediately productive.
Obviously, there's domain-specific knowledge that doesn't transfer easily or quickly from project to project. But that's quite different from self-inflicted code fragility; one's an asset and the other's a liability.