Monorepos: Please don’t • Hacker News Board

Re: Monorepos: Please don’t

#261

Post by yowlingcat » Thu, Jan 03, 2019, 2:52 PM UTC

btschaegg wrote: post #127

wcdolphin wrote: post #97

Earlier quoted context omitted.

No. The worst case is that the engineering team spent more time working on “well encapsulated projects” than on the most important project for their business and are all now out of jobs. Most companies don’t fail because of tech debt. And certainly not because of version control tech debt.

Not exactly. (At least small) companies can go out of business because of bugs. And one great way to "achieve" said bugs are implicit dependencies hidden from developers that didn't introduce them. > The worst case is that the engineering team spent more time working on “well encapsulated projects” than on the most important project for their business I'm not really sure how I should read this. Don't you use your rep…

Small businesses are not going to go out of business because of bugs unless those bugs aren't addressed. They'll go out of business because of poor sales and product management. Different things.

Re: Monorepos: Please don’t

#262

Post by bborud » Thu, Jan 03, 2019, 2:53 PM UTC

rossjudson wrote: post #148

Hilariously misguided. Pretty funny to read that the things I do every day are impossible. Monorepo and tight coupling are orthogonal issues. Limits on coupling come from the build system, not from the source repository. Yes, you should assume there is a sophisticated "VFS". What is this "checkout" you speak of? I have no time for that. I am too busy grepping the entire code base, which is apparently not possible. If…

It can work. That doesn't mean it is a universal solution. And it doesn't even mean it is a solution that is guaranteed to cover most projects. Whether or not a monorepo works depends on a lot of factors. In my experience the number of cases where it doesn't work appears to outnumber the cases where it works.

It can work nicely when you have disciplined and demonstrably above average programmers that are good at structuring the internal architecture of systems and will know how to design for plasticity. It is also an advantage if all your code is written in the same style and doesn't come from a bunch of older codebases. But even then you can end up with messes that you will be likely to conveniently forget about.

For instance while clear decoupling was a goal when I worked at Google, it wasn't always a reality. There were still lots of very deep and direct dependencies that should never have been there.

It does not work well if you have "average" developers or if you have undisciplined developers or excessive bikeshedders (which kill productivity).

Then there is the tooling. Most people do not work for Google and do not have the ability to spend as much money and time on tooling as Google does. What Google does largely works because of the tooling. It would suck balls without it. To be honest: some things sucked balls even with the tooling. Especially when working with people in different time zones.

Google isn't really a valid example of why monorepo is a good idea because your average company isn't going to have a support structure even remotely as huge as Google. (If you disagre: hey, it's easy, go work for Google for a while and then tell me I'm wrong)

Re: Monorepos: Please don’t

#263

Post by EngineerBetter » Thu, Jan 03, 2019, 2:53 PM UTC

fnord123 wrote: post #244

EngineerBetter wrote: post #95

Visited a customer recently who had inherited a monorepo. All their CI and release problems traced back to it. At the risk of sounding like an old git, package coupling and package cohesion principles were defined for a reason. I do feel like a lot of patterns in contemporary development are kneejerk reactions to how last generation's programmers did things. Exceptions? Nah, multiple returns! Dependency management? W…

>Exceptions? Nah, multiple returns! Dependency management? Who needs it... Oh, wait. I thought consensus was that exceptions, like OOP, is an antipattern. I guess there's room for different opinions. :-/

Consensus could be a synonym here for 'current trends'.

I see no advantage of returning error types over checked exceptions. I'm happy to be informed, though.

Re: Monorepos: Please don’t

#264

Post by drugme » Thu, Jan 03, 2019, 2:54 PM UTC

yowlingcat wrote: post #256

I think this article is complete horseshit. A monorepo will serve you 99% of the time until you hit a certain level of scale when you get to worry about whether a monorepo or a polyrepo is actually material. Most cases are never going to get there. Before that point, a polyrepo is purely a distraction and makes synchronous deployment really painful. We had to migrate a polyrepo to a monorepo and it was not fun becaus…

I found it to be neither horseshit nor irresponsible. A bit overdrawn and skewed in some of its arguments, perhaps. But then again... so was your critique. For example:

We had to migrate a polyrepo to a monorepo and it was not fun because it was a migration that should have never had to be done in the first place

s/polyrepo/monorepo/ in the above and you have an assertion of about equal plausibility and weight.

Re: Monorepos: Please don’t

#265

Post by [deleted] » Thu, Jan 03, 2019, 2:54 PM UTC

laurencei wrote: post #64

Can anyone here explain to me how a monorepo like Google or Facebook handles security? If I pull the repo - I have the entire contents of Google or Facebook? Is that right? Surely that lacks the normal security measures around what must be highly sensitive information, so there must be more to it than I know of?

[deleted]

Re: Monorepos: Please don’t

#266

Post by yowlingcat » Thu, Jan 03, 2019, 2:55 PM UTC

wtracy wrote: post #60

I'm not familiar with how monorepos work in practice, but it seems obvious to me that it's going to complicate everyday tasks. Ready to commit? Whoops, another team made a bunch of commits to their project, and you need to rebase your project before you can commit. (I'm having flashbacks to Clearcase already.) Need to roll back the last two commits you made? Sure, that takes two seconds--oh, wait, another team made m…

You're not a curmudgeon, you're just wrong. As another comment states, you'd have to fix the merge conflict anyways and if there's no merge conflict, your rebase isn't an issue. If you're getting merge conflicts and need to rebase your project and that's challenging, it turns out to be an...organizational issue.

Re: Monorepos: Please don’t

#267

Post by kiallmacinnes » Thu, Jan 03, 2019, 2:56 PM UTC

thedufer wrote: post #241

Maybe its just that the author's cutoff is at the wrong team size, but the monorepo I work on (with ~150 devs) has almost none of the problems presented. Unreasonable for a single dev to have the entire repo? I'm looking at a repo with ~10 million LoC and ~1.4 million commits. I have 74 different branches checked out right now. Hard drives are cheap . Code refactors are impossible? I reviewed two of those this mornin…

In theory, yes - if the underlying repo changes, code review should start over. In practice though, it's a terrible idea ;)

Part of code review is to ensure the code "fits" with all other merged code - so a re-review is "needed" when other changes merge. E.g. if I merge a refactor that changes everything from Pascal case to 100% SHOUTING, reviews now need to take this into account.

In practice, this doesn't happen - it's way too much effort for far too little value.

Re: Monorepos: Please don’t

#268

Post by drugme » Thu, Jan 03, 2019, 2:56 PM UTC

inertiatic wrote: post #175

mrgriffin wrote: post #14

My problem with polyrepos is that often organizations end up splitting things too finely, and now I'm unable to make a single commit to introduce a feature because my changes have to live across several repositories. Which makes code review more annoying because you have to tab back and forth to see all the context. It's doubly frustrating when I'm (or my team is) the only people working on those repositories, becaus…

My current team managed to break a single "component" out into a separate repository. Then that repository broke into two, then those broke into other repositories, until we've eventually have around 10 or so different repositories that we work on every day. An average change touches 4 of them, and touching one of them triggers on average releases on 2 or 3 of them. Even building these locally is super tedious, becau…

even if they are heavily coupled,

So don't use polyrepos for heavily coupled projects, then. Or even better...

... try to avoid heavy coupling in the first place.

Re: Monorepos: Please don’t

#269

Post by yowlingcat » Thu, Jan 03, 2019, 2:57 PM UTC

drugme wrote: post #264

yowlingcat wrote: post #256

I think this article is complete horseshit. A monorepo will serve you 99% of the time until you hit a certain level of scale when you get to worry about whether a monorepo or a polyrepo is actually material. Most cases are never going to get there. Before that point, a polyrepo is purely a distraction and makes synchronous deployment really painful. We had to migrate a polyrepo to a monorepo and it was not fun becaus…

I found it to be neither horseshit nor irresponsible. A bit overdrawn and skewed in some of its arguments, perhaps. But then again... so was your critique. For example: We had to migrate a polyrepo to a monorepo and it was not fun because it was a migration that should have never had to be done in the first place s/polyrepo/monorepo/ in the above and you have an assertion of about equal plausibility and weight.

No, it is horseshit. 99% of companies will never hit big company VCS scaling issues, and once they do, they're on their own. To characterize that scale as common is one of the most embarrassing failures of modern software engineering. People are so embarrassed to use well worn tooling and accept that large scale is both uncommon and something that doesn't invalidate tried and true patterns for smaller scales. It's utterly baffling to me.

Re: Monorepos: Please don’t

#270

Post by hennsen » Thu, Jan 03, 2019, 3:02 PM UTC

To sum up the discussion of why this is either absolutely right / absolutely wrong, How about: „mono/poly-repo - none of both is THE single solution for every usecase in every organization and project“? Besides that, sure let’s keep analyzing the pros and cons of each in different scenarios...