“Adding manpower to a late software project makes it later”. The so-called Brooks’s Law on productivity of software project is well known, since Fred Brooks’ seminal work The Mythical Man-Month, first published in 1975.
That is one of the reasons I’m wince a little when a company talks about plans to hire lots of software developers.
This recent study by QSM seems to prove me right. Its conclusion seems to be that Brooks’s Law can be extended to projects that are not late. At any rate, code is not produced at a faster pace with more manpower.
The idea was to compare the time require to build a 100,000 lines projects, depending on the size of the teal. Results are :
- 32-people teams : 8.9 months
- 4-people teams : 9.1 months
That’s a one-week difference. 2-3%!
Costs are obviously much in favor of small teams (roughly 8 times cheaper for the same result!). One of the reasons suggested could be that large teams produce many more bugs.
Unfortunately, there are no discussions on other possible explanations, such as complexity in coordinating, communication, the number of managers, location over multiple rooms or sites, skills, turnover, size of the company… I would have also liked to see other sizes compared. Is there a productivity peak at 2 people ? 6 ? 4 ?
A few years ago, I got into a discussion where one of the persons remarked: “managing large teams is hard!” As far as as I’m concerned, the answer seems to be: “well, don’t do it, then.”
I’ve read/heard that development productivity follows a gaussian function with its peak at 5/6 developpers.
I’m willing to believe that, but I would like see some kind of scientific-ish study.
I once read somewhere that the C guy (must be Kerninghan or Ritchie) said that in a dev team, the quality of the code can not be better than the quality of the weakest developer. This is how I’ve experienced things as well, small teams, specialised skills and you can hope for delivery. Lots of suits, lots of arms waving, lots of time wasted…