[tshaddox]

If you're talking about Brooks's law, that's a pretty specific observation that doesn't seem like it applies here. It's very specifically about adding workers to a project that is already behind schedule. It doesn't certainly doesn't mean anything as broad as "a company cannot do more things by increasing its employee count."

[quonn]

But of the reasons Books gives, most apply regardless of the project being late, such as the communication overhead and the fact that splitting the project neatly is difficult.

[tylerhou]

Apollo is a large project with many features. I’m sure they have many teams working on relatively-self contained subcomponents.

[kristopolous]

Modern software projects are wildly different than OS/360.

The insights from 50 years ago is fine abstractly but it has its limitations.

Not only are there many more roles to fill but things like translation and QA scale pretty well.

It's an adage, not a hard and fast dogma.

Also it was specifically limited to when in the project people are added and often gets misremembered as some linear programming inspired exercise in optimal team configuration.

The latter is obvious and useful (right size the team for the job) but IIRC, Brooks doesn't actually address it in the famed literature.

[Rooster61]

I don't think I've ever worked on or even seen a software project that wasn't in some way considered behind schedule. Very, VERY rarely are the correct number of people hired at the beginning.

[Aeolun]

I’m fairly certain that even without them all working on the same thing, 2.5x more employees will never be 2.5x faster.

[majormajor]

Sometimes it's less, sure.

Sometimes it's more! You have nine projects you want to do. A, B, C, D, E, F, G, H. You have 2 developers. You hire 3 more. One of the new hires has more familiarity with what projects E and G needs than anyone on the existing team had. One of them is slower than the average of the existing devs. One of them is MUCH faster. The five of them complete those nine projects in three months (15 total people months, with boosts from one of the new dev's skills and the other's increased speed) when it may have taken 9 otherwise (18 total people months).

But I've seen a lot of companies not be quite that smart in their hiring...

(The faster scenario I've outlined above also potentially bites you in the butt if you don't have enough more valuable projects lined up behind that first set...)

[ctvo]

Did anyone claim a linear (let alone 1:1) gain?

This was the relevant part of what you replied to:

> It doesn't certainly doesn't mean anything as broad as "a company cannot do more things by increasing its employee count."

[0x457]

There is a sweet spot for how many people should be on a team. That number depends entirely on a nature of tasks. I would even go as far as to say - in a good environment up to that sweet spot, productivity gain is linear.

And yes, managers do expect close to linear productivity gain past that spot. Managers, that are a little smarter, start thinking about how spotify did squad (without actually knowing anything about it).

[adolph]

The term "Two pizza team" comes from Amazon and describes a team size such that it is the number of people that can be fed by two pizzas. The reality is that the term is not only a reference to team size but, rather, underscores the concept of "Accountability".

https://developers.redhat.com/blog/2022/10/21/coming-terms-t...

I think a well composed small team can have greater than linear improvement in effectiveness because of skill stretch and decreasing blindspots.

[0x457]

Huh, didn't know there is a term for that.

What I was talking about is something like this: SRE team has 1 member and productivity of 1, that person is overworked and if vacation is taken productivity goes to 0.

Hire second person, after onboarding productivity goes to about 2 (i.e. linear scale). Hire third person, productivity will probably be a little under 3 because now they need to spend time to be on the same page. Vacation is still shaky because with such small team, knowledge will be 100% siloed due to outside performance expectations ("hey you worked on X last time, I'm going to assign this ticket to you" repeated many times).

Eventually team grow to a point where they can handle all work load, share knowledge between each other and take vacations without fear (btw if you fear taking vacations - don't, it's not your fault if team can't handle without you).

You can think of "work load + process" as a data structure. If work load is bog and process requires a lot of synchronizations (every meeting is essentially a Mutex for the entire team) - you won't get linear productivity increase, instead you will increase lock contention.