How do I explain the overhead of communication between developers in a team?

Question

Other than just saying read Mythical man month, how would you explain to a project manager that although two programmers will do close to twice the work of one programmer, 10 programmers probably wont do 10 times the work.

Answer 1

Explain to the PM that managing the traffic of a 4 way stop is considerably straight forward and easy to manage. One person comes to the stop. The next person comes to the stop. The first person gets to go. But when you have 10 developers on a team it is like managing one of those round abouts in DC or a major freeway intersection where you have many cars coming and going from all directions. No one knows what is going on so everyone stops to see what the next guy is doing.

Managing two developers is similar in that A talks to B and B talks to A. Adding C is even ok as the conversation is small enough that everyone can keep up.

Have A through J all keeping track of one anothers tasks is difficult even for the PM...so to expect the developers to not get caught up in conversation regarding who is doing what is not exactly unexpected.

Answer 2

Ask your project manager to imagine herself in a conference room. She has been asked to design a car from scratch, down to the last bolt, in 10 weeks. If we put 9 other people in the room, would the design be finished in one week? Probably not.

The main problem is that people believe software development is more akin to building the car than designing it, which is obviously not the case. All cars share common concepts (combustion engine, steering wheel, threaded screws) and we reuse common concepts in software development, but their particular arrangement and specific goals vary enough to require creative time, which is orthogonal to man-time. If building software were like building cars, we would be working against a finished technical blueprint. We are developing the blueprint.

Answer 3

It all depends who your audience is.

You could always try using a business proposal as an example. If you put two people in a room and ask them to write a business proposal, they can resolve conflict fairly easily and make everything flow pretty easily. If you toss ten people on that same project, you're going to have ten very different ideas and instead of getting something done ten times as fast...you're going to get something that doesn't mesh and takes an order of magnitude longer to produce.

Answer 4

I don't believe explaining a PM how to do the job is a good idea, nor appropriate, not from team member point of view anyway (will probably do more harm than good). This is probably a Senior PM's responsibility to take the PM aside and tackfully explain the idea behind combinations.

The other way is to present the problem to PM and let them solve it by making a polity one-to-one off-the-record remark that you're concerned with the inefficiency of current communication model used for the project.

Answer 5

If a project manager needs that explained to them, than there's a bigger issue. The downside to team effectiveness is communication, control and coordination. You can easily explain going from 1 to 2 people - the code control needed, the coordination of promotions, the integration points and overall project/coding approach - going from 4-5 is a bit more difficult - it's the scale of team change that really matters (going from 150 to 151 has little impact)...get specifics, get prior history at your company in regards to single person projects to team projects - base the response on specific metrics if you can.

Here's a good article for reference:

• http://www.stevemcconnell.com/articles/art06.htm - less is more
-

Answer 6

Good stuff so far. Also, remember that it is not quite as cut and dry as many readers of the Mythical Man Month (and those who haven't read it either) would have you believe. Perhaps he/she has already considered these effects.

i.e., Adding people to a late project will only make it later.

The important thing to understand is the effect of adding a single person to a project and how it will impact the rest of it. However, that's not to say you should never add people to them.

If they are required for a particular skill set that is lacking in the project, then you have to.

If you can limit the communication that they have to have with the rest of the project, then you do far impact to the communications costs.

That said, a good project manager should already be breaking his/her team up into logical cells to minimise the required cross talk (and acting as that channel/filter).