3 ms·
Doesn’t this create a single point of failure for the development of the entire software ecosystem at google? What happens if something goes disastrously wrong
by randomsearch 9y ago
Doesn’t this create a single point of failure for the development of the entire software ecosystem at google? What happens if something goes disastrously wrong with their repo? Does everyone twiddle their thumbs until it gets fixed?
Also, isn’t this is the opposite of “separation of concerns”... code should be divided into small units of functionality that don’t overlap. Minimise interdependencies. Eliminate unnecessary work. Is this the most efficient and future-proof approach?
- boulos 9y agoYes, when the system is down, it's really bad. Though it's an extremely reliable system as so many folks depend on it (note there's also lots of layers of tooling, so maybe you just need commits to work versus code review versus your local edits, etc.). In my experience, the worst things are actually when the build/test system is running slowly (thus blocking commits until tests are complete) or the bog standard "ugh, someone decided to force submit even though it said the tests were failing. Roll that back, please". As for separation of concerns, there's actually a lot of scoping / visibility stuff precisely to avoid letting people depend on things they shouldn't. I think you now have to explicitly open up your visibility to let random other projects depend on you. A monorepo doesn't require that you share, it just permits it.
- randomsearch 9y agoInteresting. Every system is going to be down times, so I don't worry about that too much. I'd be more worried about a design flaw or bug that doesn't get exposed until you're painted into a corner and it's hard to escape. Good point about the scoping. I suppose it really depends on how developers use it - do they default to sharing or not?