There is an apocryphal story1 during World War Two, of a squadron of bombers leaving on a sortie. Time passes and finally a few bombers struggle back to their base, the crew shaken, but alive, their aircraft riddled with bullet holes.
Shocked by their losses, the reaction by Air Force was to order the areas of the air frame wounded by enemy fire be reinforced with additional armor plating to improve the success of future missions.
Fortunately for the Allies, a statistician engaged by the British raised the issue that the aircraft that had returned, although battle scared, were hit in places not crucial for flight. In comparison, their missing comrades had not fared so well. Having succumb to enemy fire, the damage their aircraft suffered could not be accounted for.
Thus, the statistician argued, the portions of the aircraft which should receive additional armor should the places which did not suffer damage. This then is a tale about Selection Bias.
Thirty years later, Frederick P Brooks, Jr wrote his seminal work, The Mythical Man-Month. Brooks’ observation that “adding manpower to a late software project makes it later” has become a rallying cry for the software development industry; one which we have had no shortage of opportunities to validate against a steady stream of prominent projects who over promised yet under delivered.
However, for all our well founded chortling, I wonder if we are not succumbing to our own selection bias. For all the attempts to throw people at a floundering project is there a percentage of teams that quietly pull it off, meet their audacious schedule and live to code another day ?
Is Brooks’ law an axiom of the software development industry, or are we simply counting the losers and drawing the wrong conclusion?
- If you want the real story, I suggest reading John D Cook’s post.
Generally 3 reasons why a project could be late. 1. bad(not detailed enough, no flexiblity, solutions embeded in them) or constantly changing requirements. 2. Bad technical estimates(Technical people aren’t experienced enough in that area). 3. Someone cut estimates up that chain. Solutions: 1. late in the game tough to deal with but you need more commitment from the business more expreienced BAs and project managers. 2. need more expienced architects or senior devs to reestimate. unless you way off probably better to just keep chugging along. 3. most common. probably screwed. they probably haven’t learned going to get the cheapest bodies they can find to add to the project good luck.
Also, might want to look into more iterative methedolgies so you can deliver smaller more easily managed chunks.
IMO it depends on why the project is failing – there could be multiple reasons, including that the project needed more people, and/or did not have the right kind of people.
I have seen projects get back on track, or at least improve their meeting of milestones, with the addition of the right people. When you have parallel projects and some of the people are working on multiple projects simultaneously, or you pull people off one project to work on another, adding the right kind of people to either project might help one or both projects.
A LOT depends on the nature of the projects, the experience and skill of the people who are working on the projects and who is added to the projects to help.
If a project is ill defined, the people working on it are not the right people, and the management of the project is poor, then yes, adding more people will probably result in more chaos and less productivity.
It just depends. If adding more people always resulted in the project taking longer, then the ideal number of people for any project would be zero.