3 ms·
> Separate repos for each team means that when two teams own components that need to interact, they have to expose a "public" interface to the other team--which
by The_Colonel 2y ago
> Separate repos for each team means that when two teams own components that need to interact, they have to expose a "public" interface to the other team--which is the kind of disciplined engineering work that we should be striving for.
This pattern has its own set of problems. Strict ownerships separation creates strong dependencies and capacity constraints on the project organization. A single team is rarely able to deliver a complete feature, because it will mean changes in a couple of services. If you go with a model where teams are allowed to build features in "foreign" services, you will still come to the situation that the owning team doesn't feel that responsible for something they haven't built / don't really understand. You can tweak it, involve the owning team more etc. but it has trade-offs / friction.
The worst anti-pattern coming from this is "we have dependency on service X / team Y, but their code reviews are usually very long and pedantic, threatening our delivery. Can we do it locally in our service instead?" which results in people putting stuff where it doesn't belong, for organisational reasons.
- __MatrixMan__ 2y agoI'm not saying that the ownership should be strict, you should feel free to submit PRs to my repo, and I to yours. I just don't want there to be a no-man's-land. And if there must be an every-mans-land, let it be explicitly so, not some pile of stuff that didn't fit anywhere else.
- jatins 2y ago> you should feel free to submit PRs to my repo, and I to yours Haven't seen it happen in practice. For some reason a separate repo induces more of "not my backyard" feeling that a separate folder
- __MatrixMan__ 2y agoReally? GitHub is packed with commits authored by people besides the maintainers. Have your really not noticed? Or do you just stop looking for a CONTRIBUTING.md when you're at work?
- The_Colonel 2y agoThat's good, but that still produces friction AND reduces the sense of the ownership of the owning team. > I just don't want there to be a no-man's-land. A different model I've seen is that the ownership of the whole system is shared across the trusted senior members (every team has one, but you need to get an approval from an external one). One thing this avoids is the bottleneck on specific teams (only team X can approve the PR, but they're now super busy with their own features).
- __MatrixMan__ 2y agoThats what we're trying to do. I'm not one of those people, but golly they seem overworked.