4 ms·

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 t

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

Rooster61 4y ago
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.
quonn 4y ago
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 4y ago
  Apollo is a large project with many features. I’m sure they have many teams working on relatively-self contained subcomponents.
- kristopolous 4y ago
  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.
Aeolun 4y ago
I’m fairly certain that even without them all working on the same thing, 2.5x more employees will never be 2.5x faster.
- ctvo 4y ago
  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 4y ago
    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 4y ago
      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-two-pizza-team 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 4y ago
        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.

Rooster61 4y ago

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.

quonn 4y ago

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 4y ago
Apollo is a large project with many features. I’m sure they have many teams working on relatively-self contained subcomponents.
kristopolous 4y ago
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.

Aeolun 4y ago

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

ctvo 4y ago
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 4y ago
  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 4y ago
    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-two-pizza-team 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 4y ago
      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.