[ofrzeta]

I haven't read it but from what is commonly quoted it is about "Adding manpower to a late software project makes it later."

So the assumption of bringing n people to work on a projects increasing the productivity n-fold doesn't seem totally absurd when they are working on the project from the beginning. It might not be exactly n but (n-m) due to increased management, communication etc. So we might discuss how big is m? Still there should be some increase in productivity because that's essentially how huge projects work.

[alex_anglin]

It's worth a read, if just to consider that many of the observations made in the industry during the 70's hold true today. Wikipedia has a summary of the book[1].

[1] https://en.wikipedia.org/wiki/The_Mythical_Man-Month

[astrobe_]

You can push it to the extreme and have two persons on each and every coding task. That's pair programming [1], which is said to be less productive, although it is argued you trade productivity for quality and other benefits.

[1] https://en.wikipedia.org/wiki/Pair_programming

[rzzzt]

The other often repeated quote is about pregnancy.

[ofrzeta]

Yeah but software is not a baby and software can very well have modules and APIs.

[rzzzt]

It also does not like to be split cleanly into as many parts as there are people working on it; development work is not an embarrassingly parallel problem.

[hinkley]

The longer people work between coordinating with others the more code has to be rewritten.

People do not like rewriting code, so add time for all the bickering.