We, developers, are optimists.
Though we are not so delusional as to think that the development process will run “perfectly”, we believe anything can be overcome with grit, mental sweat, and caffeine. We see the light at the end of the tunnel, and endure because of the pure joy of creation. Our work is pure “thought-stuff”, so it’s completely in our control, right? Fifteen people on a project will be quicker than five, surely.
If the project is broken up into completely compartmentalized bits, which don’t relate to each other in any way – then, maybe. In reality though, software is made up of a complex network of interdependency. We must also factor in communication between all of the moving parts. If certain parts need to be built in a certain order, this may slow the process even more. One managerial view might be that if more people are added, these pieces will get done faster. This is also a tempting thought if the project is running behind schedule.
So, for a project that is already behind schedule, new people must be trained by someone already on the project, taking them away from the work at hand. After the new person is up to speed, they may be given a slice of the work-load pie – which increases the need for more communication between the moving parts.
Though the notion of “more men = less time” may hold true for something like cutting down a forest, it does not equate to software development. The opposite doesn’t hold true either. If you give one person, one project, this cuts down the communication needed between these parts to zero. However, they are still one person. The amount of men does not directly correlate to the amount of months a project will take. There is no ratio where “men” and “months” are interchangeable.
This has caused me to rethink my notion of “assembly”, and to abandon the notion that dividing up a task between more people is somehow faster. Care must be taken in using remedies from other fields to streamline the software development process.
Check out “The Mythical Man Month” by Frederick P Brooks Jr. for more data on the subject.