4 ms·
I like the blog post and broadly agree with the conclusions, but I want to double down on something in the article: > Shared pain I've worked in some orgs wit
by Joe8Bit 5y ago
I like the blog post and broadly agree with the conclusions, but I want to double down on something in the article:
> Shared pain
I've worked in some orgs with very large monorepos (1000s of developers working in a single repo) and broadly have had positive experiences with them, but this 'shared pain' was by FAR the biggest drawback I experienced. When things went wrong with the monorepos they tended to go VERY wrong and effect EVERYONE. Multiple incidents of the monorepo just crushing productivity for 1000 person engineering orgs, for a period of time.
That's not to say I think monorepos are bad, it's 100% context dependent whether they make sense for your org in my experience, but I learned that the same tradeoffs you get with architectural monoliths/distributed systems often apply to multi/mono repos as well.
- dandigangi 5y agoSame experience. It's interesting because we've had great success on our internal design lib's monorepo compared to the overall application. Which makes sense in some regards.
- purplerabbit 5y agoThe fact that you split your design lib from your "overall application" suggests that what you are describing is not, in fact, a monorepo pattern :)
- dandigangi 5y agoThere's a split between our orgs. DocuSign runs a mono repo. But the big product I work on has its own giant mono repo. Design lib is another giant mono repo comprising general front end things also.