Hacker News Reader

I think the calculus changes when you consider teams with 1000s of programmers committing 100s of changes per day. Keeping feature branches up-to-date can pretty quickly adds up to a lot of time and creates a lot of friction for refactoring/cleanup-type changes.

Feature toggles enable some additional cool stuff like partial/incremental rollout and A/B testing, which really pay dividends.

View on HN

I've never worked on codebases with so many programmers, but I kind of feel that's if that's how you work, 'you're doing it wrong'.

Why would you have so many programmers working on a single codebase, why not split it up in distinct parts? If that's not possible because so much stuff is shared, how can you possibly work effectively with so many people changing so many things?

1000 programmers on a single codebase means:

• "master" always builds

• "master" is always stable

Any testing has to be done with in-code branches, and has to be built in-place incrementally so that other developers can see you touching stuff (and can be defensive about their tasks).

Reply on news.ycombinator.com