4 ms·

You're not the first to make this claim, but it seems dubious. It means the library authors must be knowledge expert on all projects using the library. How can

You're not the first to make this claim, but it seems dubious. It means the library authors must be knowledge expert on all projects using the library. How can you make changes to all the client code without knowing the code base well? Make change willy-nilly on codebase you are not familiar with on the basis that it uses your library? That sounds like a recipe for disaster. Or you need to get consensus and code review for each and everyone of those projects and have all tests pass for all projects. This look like slow-as-molasse progress. Submitting any changes would always be an extremely big endeavour. The alternative is to have submit not affect other projects. You can do this in a monorepo by mandating that other projects not sync to head but to a given release tag of your library and only move to a more recent tag on their own schedule, after they've tested the upgrade. IOW, pretty much how a packaged release would work. Pretty much how one would have sync'ing to separate repos. I fail to see what are the benefits or monorepo. The downside is either anyone can touch anything without being and expert and having an extremely long and complex submission process. (And woe to you if someone submitted something in the meantime... you have to redo your testing and fixing again?!?) The world at large has lived with separate repos and explicit releases for ages. That's how third-party library are handled in every single software team I've ever seen.

DannyBee 10y ago
"You're not the first to make this claim, but it seems dubious." "It means the library authors must be knowledge expert on all projects using the library." They must know enough to design good APIs or else you will fail anyway. If your apis require expert knowledge of the system to use correctly, you've probably done it wrong. " How can you make changes to all the client code without knowing the code base well?" Good API and good refactoring tools " Make change willy-nilly on codebase you are not familiar with on the basis that it uses your library?" With good tests and testing tools, i fail to see the issue. "Or you need to get consensus and code review for each and everyone of those projects and have all tests pass for all projects. This look like slow-as-molasse progress. Submitting any changes would always be an extremely big endeavour. " Nope, there are tools to manage the changelist process for large refactoring tools. My experience says velocity is not an issue in terms of things moving too slow, pretty much ever. "The alternative is to have submit not affect other projects. You can do this in a monorepo by mandating that other projects not sync to head but to a given release tag of your library and only move to a more recent tag on their own schedule, after they've tested the upgrade. IOW, pretty much how a packaged release would work. Pretty much how one would have sync'ing to separate repos. " Try this sometime, and see what the lag time to upgrade in a large enough set of teams and environment is. It's "forever until someone breaks you". "I fail to see what are the benefits or monorepo." I think they've been covered quite well. You just think they don't happen in practice, despite people with experience saying they do. That's okay. you don't have to believe them, but it's not clear what anyone could do to convince you:) " The downside is either anyone can touch anything without being and expert and having an extremely long and complex submission process." The first is an explicit feature. If everyone needs to be an expert to touch most of your codebase, that sounds like a bad codebase to me. Your latter is simply not correct. The rate of change is many times faster than any separate repo process i've seen. " (And woe to you if someone submitted something in the meantime... you have to redo your testing and fixing again?!?) " If it's broken, it's broken, whether it's packaged or not. The only thing you are talking about is whether you can tell it's broken before you get to the next packaged release. "The world at large has lived with separate repos and explicit releases for ages. That's how third-party library are handled in every single software team I've ever seen. " Yes, and honestly, it's been a complete and total disaster everywhere i've seen it, with tons of teams with forked, old, buggy versions, the inability to reuse code (or bugs) because of subtle third party dependency incompatibilities, etc. I'm not sure why you claim it's a panacea. Neither is, but not for the reasons you've given.
defen 10y ago
The facts on the ground suggest that Google does not have trouble delivering high-quality software, so your arguments aren't very convincing. To me the biggest issue is that their customer-facing software is often not what people want, but that isn't really a development process issue.

DannyBee 10y ago

"You're not the first to make this claim, but it seems dubious." "It means the library authors must be knowledge expert on all projects using the library." They must know enough to design good APIs or else you will fail anyway. If your apis require expert knowledge of the system to use correctly, you've probably done it wrong. " How can you make changes to all the client code without knowing the code base well?" Good API and good refactoring tools " Make change willy-nilly on codebase you are not familiar with on the basis that it uses your library?" With good tests and testing tools, i fail to see the issue. "Or you need to get consensus and code review for each and everyone of those projects and have all tests pass for all projects. This look like slow-as-molasse progress. Submitting any changes would always be an extremely big endeavour. " Nope, there are tools to manage the changelist process for large refactoring tools. My experience says velocity is not an issue in terms of things moving too slow, pretty much ever. "The alternative is to have submit not affect other projects. You can do this in a monorepo by mandating that other projects not sync to head but to a given release tag of your library and only move to a more recent tag on their own schedule, after they've tested the upgrade. IOW, pretty much how a packaged release would work. Pretty much how one would have sync'ing to separate repos. " Try this sometime, and see what the lag time to upgrade in a large enough set of teams and environment is. It's "forever until someone breaks you". "I fail to see what are the benefits or monorepo." I think they've been covered quite well. You just think they don't happen in practice, despite people with experience saying they do. That's okay. you don't have to believe them, but it's not clear what anyone could do to convince you:) " The downside is either anyone can touch anything without being and expert and having an extremely long and complex submission process." The first is an explicit feature. If everyone needs to be an expert to touch most of your codebase, that sounds like a bad codebase to me. Your latter is simply not correct. The rate of change is many times faster than any separate repo process i've seen. " (And woe to you if someone submitted something in the meantime... you have to redo your testing and fixing again?!?) " If it's broken, it's broken, whether it's packaged or not. The only thing you are talking about is whether you can tell it's broken before you get to the next packaged release. "The world at large has lived with separate repos and explicit releases for ages. That's how third-party library are handled in every single software team I've ever seen. " Yes, and honestly, it's been a complete and total disaster everywhere i've seen it, with tons of teams with forked, old, buggy versions, the inability to reuse code (or bugs) because of subtle third party dependency incompatibilities, etc. I'm not sure why you claim it's a panacea. Neither is, but not for the reasons you've given.

defen 10y ago

The facts on the ground suggest that Google does not have trouble delivering high-quality software, so your arguments aren't very convincing. To me the biggest issue is that their customer-facing software is often not what people want, but that isn't really a development process issue.