Optimal team size: Brooks' Law

[nelsonic]

https://en.wikipedia.org/wiki/Brooks%E2%80%99_law

@iteles I don't know where to add this... but I feel it should be included in our "Advise to Non-Technical Founders" ...

Brooks' law is an observation about software project management according to which "adding human resources to a late software project makes it later".

According to Brooks, there is an incremental person who, when added to a project, makes it take more, not less time. This is similar to the general law of diminishing returns in economics

[Cleop]

@nelsonic - were you looking for a brief definition/ summary of this to be included in this repo's readme? What take aways or practical learnings did you want to be given from it?

[nelsonic]

@Cleop yeah, we need a section on "optimal team size" with a link to this explaining that more often than not adding people to a team slows down delivery. We should briefly explain why effectiveness/efficiency declines with too many people.

• Time to learn and get up-to-speed with context/codebase
• Existing (productive) team members time occupied by reviewing new (far less productive) team members work at the expense of getting on with their own. i.e. output is cut in half not "doubled"!
• Overlap and "stepping on toes" where features are not isolated enough leads to merge conflicts (where one person's work can "undo" someone else's) which can take up way more time.

Best time for the whole team to start is at the "ideation" or "Design Sprint" stage. Adding people to the team when the deadline is nearing more often a strain on existing members than a "boost" to the team.