Hacker News Reader

Comment by jqcoffey | Hacker News Reader

> Brook's law is also outdated. It's mostly only relevant for when you deliver your software with a forklift.

Hmm... not sure I agree with this. A few points come to mind:

- Some portions of a project become hotspots at different times and have a natural code concurrency limit (it may not be 1, but certainly 10 people can't make changes to the same class or other critical code path concurrently)

- Onboarding is a real thing. It requires current staff to train newcomers, at the very least. At worst, they have to account for the newcomer's coding/architectural misses

- Communication and consensus building with more folks takes exponentially more time (or is it combinatorial, I can't keep that straight).

View on HN

In a SaaS world the value stream is broken up and delivered as appropriate. What does it mean for a project to be late if there is a value stream constantly being delivered?

Onboarding is a real thing but Brook's calculations are absurd by today's standards. 1 Month to onboard someone? We have developers committing code in their first week. Sometimes day 1 or 2.

Read McConnell's essay. It's v. good.

At Google, engineers start committing code in their first week too.

That doesn't mean they're fully on-boarded until 6 months in.

> We have developers committing code in their first week. Sometimes day 1 or 2.

If you're doing anything complex (which can just be: if your codebase is more than a year or so old) than the quality and velocity of code someone can contribute on day 1 is vastly lower than they can a month later.

I see the Mythical Man Month tossed around as an excuse for not trying sometimes - by people who haven't even tried to split up and spread out chunks of work in parallel - but onboarding cost is definitely real.

You gotta evaluate "can I get enough overall throughput at this point in time to make up for the total efficiency lost" and also the rest of the business priorities outside of this one project.

I was on a project where we added 6 people to an 8 person team in 2 weeks. Velocity stayed exactly the same as before for a sprint or two but quality issues jumped. We then spent an enormous portion of time on bug fixing. It took about 2 months before the overall team really saw a net benefit to velocity by adding those people.

Brooks exact numbers might be come from a different time, but the principle holds unless you have an uncommonly decoupled set of problems.

Reply on news.ycombinator.com