However, I’ve worked on projects with well over 100 people regularly committing to a single branch without stability problems. I think it’s a matter of having appropriate tools to (1) detect regressions promptly and (2) prevent regressions from happening in the first place.

My guess is that teams that only focus on “detection after the fact” rather than prevention are the ones whose processes start breaking down around ~100 engineers.

Computers (especially headless desktop PCs) are so cheap these days; compare the cost of buying an appropriately sized build farm to the cost of hiring an engineer. It’s a bargain if it saves you any time at all.

I tend to agree, but I think as teams get large (an agile anti-practice I’d argue) and you have 100 people committing into the same large code base, the “everyone works on trunk” ideal starts to break down. Especially as the rate of commits times the length of the build, exceeds the capacity of the system to quickly build each commit.

In these circumstances, my favorite answer is to split the team of 100 up into component teams and build parts of the system separately. When that can’t be done, I think feature or component streams may be the least evil remaining option. I say streams rather than branches, because stream based SCMs actually allow for automatic merging from the main integration “branch” back into the ones developers are working on.

The big bang integration risk is still present, but builds off the feature streams may be independently verifiable and integrated into the integration stream at least daily. It seems like a reasonable compromise.

That said, it’s still far from ideal and you’re dead right that the cost of integration increases over time.