Quote:
Originally Posted by Dick Applebaum 
I don't think it is "profits", "costs", or "availability of talent" -- though those are factors when deciding whether to undertake a project.
Rather, I think Apple staffs [technical people] based on productivity. The biggest challenge is to balance staff size with productivity.
Often, increasing staff to accelerate output or meet a deadline, has just the opposite effect.
At IBM, we said: "Expediting... takes a little (or a lot) longer".
There have been lots of studies on "optimal team size"
Much of this boils down to "communication" as expressed in the communication formula-- the number of different communication paths (or interactions) within a group of a given size:
(N * (N-1))/2
Where N is the number of people in the group.
For example. we have a team of 5 people working on a project -- there are 10 possible communication (interaction) paths
(5 * (5-1))/2
Now, we want to expedite the project so we add 2 members to the team (assume the new members are all up to speed). Now there 21 possible communication (interaction) paths.
(7 * (7-1))/2
By increasing the team size by 40%, we have more than doubled the complexity of communication (interaction).
As the team grows, each member spends an increasing amount of his time "communicating" rather than "producing".
Soon, there will be more meetings called to "get everyone on the same page" and "up to speed".
Then, the final death rattle, when someone says: "let's have a pre-meeting, meeting-- so we can agree on a position to take to the full meeting".
Jef Bezos of Amazon is credited with defining the "Two-Pizza Team Rule".
"If a project team can eat more than two pizzas, it's too large."
http://www.learningapi.com/blog/archives/000079.html
In my experience, 5 is the optimal team size!
.

I don't think it is "profits", "costs", or "availability of talent" -- though those are factors when deciding whether to undertake a project.
Rather, I think Apple staffs [technical people] based on productivity. The biggest challenge is to balance staff size with productivity.
Often, increasing staff to accelerate output or meet a deadline, has just the opposite effect.
At IBM, we said: "Expediting... takes a little (or a lot) longer".
There have been lots of studies on "optimal team size"
Much of this boils down to "communication" as expressed in the communication formula-- the number of different communication paths (or interactions) within a group of a given size:
(N * (N-1))/2
Where N is the number of people in the group.
For example. we have a team of 5 people working on a project -- there are 10 possible communication (interaction) paths
(5 * (5-1))/2
Now, we want to expedite the project so we add 2 members to the team (assume the new members are all up to speed). Now there 21 possible communication (interaction) paths.
(7 * (7-1))/2
By increasing the team size by 40%, we have more than doubled the complexity of communication (interaction).
As the team grows, each member spends an increasing amount of his time "communicating" rather than "producing".
Soon, there will be more meetings called to "get everyone on the same page" and "up to speed".
Then, the final death rattle, when someone says: "let's have a pre-meeting, meeting-- so we can agree on a position to take to the full meeting".
Jef Bezos of Amazon is credited with defining the "Two-Pizza Team Rule".
"If a project team can eat more than two pizzas, it's too large."
http://www.learningapi.com/blog/archives/000079.html
In my experience, 5 is the optimal team size!
.
At least credit Fred Brooks if you are going to make his argument for him. But today even he says the numeric assumptions of team communications are wrong today in a properly run dev team that writes well incapsulated code and good interfaces. Technology and techniques have made those old equations way overstated... for the well run projects. The poorly run ones are still affected as you noted.
Essentially you end up limiting many parts of your project to the Two Pizza Rule, but not the size of the entire project. It's not hard, but the lead has to know what they are doing and be a bit of a hardcase early on to keep the interface and encapsulation ground rules in place. It's only good dev practice in the first place, but it is amazing how much of that has been ignored over the years because of ego and not-invented-here syndrome.
Hiro's Hall of Shame ignore list: Tulkas -- because we know he wasn't born dumb.
Hiro's Hall of Shame ignore list: Tulkas -- because we know he wasn't born dumb.










