3 ms·

> 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

> 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).

fnord123 6y ago
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.
- bluebknight 6y ago
  At Google, engineers start committing code in their first week too. That doesn't mean they're fully on-boarded until 6 months in.
- majormajor 6y ago
  > 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.
- topkai22 6y ago
  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.

fnord123 6y ago

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.

bluebknight 6y ago
At Google, engineers start committing code in their first week too. That doesn't mean they're fully on-boarded until 6 months in.
majormajor 6y ago
> 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.
topkai22 6y ago
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.