[cbanek]

> the entire code base got forked, and the entire org is now held hostage by the dumbass.

> Of course in a Good team, needless dependencies would be weeded out in code reviews, and a Culture would evolve over time avoiding needless dependencies.

Really, the one consistent thing is that if you have a good team, you'll make it work no matter what tech or decisions you make (assuming you're also good enough to know when you've lost and change course), and if you're a bad team, you're doomed to failure, because, well, you're bad (by definition).

I think this article also vastly underestimates the cost and annoyance of the tooling of CI'ing a large number of repos, especially if you have to match or do some kind of cross product on the feature branches. (such as, repo A branch B can only be built with repo C branch F, but all the other repos should be master)

[jerf]

"Really, the one consistent thing is that if you have a good team, you'll make it work no matter what tech or decisions you make (assuming you're also good enough to know when you've lost and change course), and if you're a bad team, you're doomed to failure, because, well, you're bad (by definition)."

The middle ground is vast, and nuanced in many dimensions. Which is a good thing, because there sure aren't very many large, good teams (by this definition of "good").

[cbanek]

Totally agree. Also many teams aren't all "good" or "bad" people, but more a mix of people with different skillsets and viewpoints, and it's not as if all good people think you should do it one way, and bad people the other.

I think the normal case though is that there are too many cooks, and they spoil the broth. I've had teams where one person wants to go off and make their own repo just because, and can't be convinced to follow the rest of the team. Sometimes these are good people, although I find a lot of "bad" people don't want to be team players and be consistent, even if being consistent means doing something they don't like.

[mrfredward]

> repo A branch B can only be built with repo C branch F, but all the other repos should be master

This alone is pretty much what makes me prefer monorepos. If you don't have a stable interface for all of your in-house dependencies (and nobody does early on in a project), you're doomed to spend a ton of time matching branches like this. Not to mention, a naive build process of "grab the latest everything and build it" will break in that period of time when you've merged the feature branch in one repository but not the other.

[0xEFF]

All modern dependency management tools solve this problem by allowing dependencies to be specified as URI's.

[yongjik]

That comes with its own problems. You could end up spending 3 hours tracking a bug you thought you had fixed two weeks ago, only to find out that some other service is pinned to a commit three weeks ago.

[thaumasiotes]

>> Of course in a Good team, needless dependencies would be weeded out in code reviews, and a Culture would evolve over time avoiding needless dependencies.

Heh. This reminded me of a different story, which I remember vaguely enough that I'll paraphrase from memory:

> "The Excel team will never go for it. Their motto is 'Find the dependencies... and eliminate them.'"

> This probably explained why the Excel team had its own C compiler.

[hinkley]

Like a lot of things in a Good Team, dependency curation requires a tempo. This will be done, and putting it off doesn't get you out of doing it.

[mixmastamyk]

Sounds like Joel on Software.

[oblio]

https://www.joelonsoftware.com/2001/10/14/in-defense-of-not-...

[GauntletWizard]

Tooling CI into a monorepo can be nasty, too. Do I update my staging deployment for every job on every commit? You can slow down deployments pretty fast, too, and make integration a real pain.

[humanrebar]

Exactly. You have the same problem in a monorepo since the problem is validating a change actually works without breaking an unknown number of other things indirectly.

There is a little bit of a novel problem in correlating N feature branches and cloning them, but it's not that much more complicated than correlating N subprojects in a monorepo.

[pklausler]

Observation: the quality of the work done by a team is too often a MIN or PRODUCT over the members of the team, not a SUM.

[hinkley]

One of the concepts being pushed by some in the Lean community is the idea that some activities need to be bounded at all times.

You don't want people favoring starting new work while someone else is flailing on old work. The fact that they started this two weeks ago indicates it was probably higher priority than whatever you might start today. If today's work is an emergency (eg, if we could go back in time, we'd have started this immediately) then sure. But barring extenuating circumstances, go help Paul. He's been staring at that code for weeks and making no progress.

I think having a rule for how many branches/forks whatever you want to call them, can exist at once might be a good idea. Every time another opportunity to use a branch comes up, the older reasons have to defend their continued existence. Having to explain yourself over and over is a form of positive peer pressure, if potentially a little passive-aggressive (solution: use an assertive person to be the messenger).

[humbleMouse]

Umm, appoint someone or a trusted few as git admins and only allow them to merge commits?

(responding to the article contents quoted in above comment)

[grenoire]

I imagine this would add a lot overhead when the git admins are not well-versed in all subprojects of the monorepo.