Tag Archives: team

The Mythical Man-Month – book and idea review

Anniversary edition from 1995

This is one of the best books on project management I know. Frederick Brooks classic volume on software project management was first published in 1977, and updated/republished in 1995.
The book contains numerous anecdotes and essays on various insights stemming from Brook’s experiences from leading the IBM OS/360 development in the 1960’s.

The most famous statement is alluded to in the title, sometimes called Brooks Law: “adding programmers to a late project will make the project even more late”.
The main reason for this is increased time losses in communication/training for the added “resources”. Brooks goes on to show with clear examples how this works out.

In the summer of 2002 I crashed head on Brooks’ Law at the Saab Automobile factory in Trollhättan, Sweden.

Infotainment system for the SAAB 9-3, with MOST fibre-optic bus. Later than planned...

Instead of using the developer programmers to do the integration testing in the pre-production vehicles, new resources were assigned to this task, and I was asked to coordinate the efforts. It took weeks and weeks to get the new people up to speed. In the learning phase they consumed much of the time of the original developers’s time and they introduced new mistakes and miscommunications. Of course it is impossible to know for sure how it would have been if the original plan had been followed, but afterwards I felt very uncomfortable with the project decision to throw more people at the problem.

Another great insight that is eloquently explained is that it is virtually impossible to specify requirements correctly for a new system. Nobody is so smart that he/she can write down what is needed in a unique and non-contradictory way before the system exists in a prototype form.
Therefore, prototyping is a often necessary to get the requirements during the project.
This has re-surfaced as one of the cornerstones in the “Agile” programming methodology.
It is a strong insight and I see this in more domains, not only software. At the R&D lab where I now work, also mechanical designs and mechatronic solutions profit from iterative development instead of trying to get it all right at the first try.

In the coming weeks I will follow a Black Belt training for “Design for Six Sigma”, which claims to enable projects to get it right the first time. (see e.g. http://en.wikipedia.org/wiki/Design_for_Six_Sigma) I am curious and somewhat sceptical… Maybe there is a “Silver Bullet” after all?

I recommend this book to everybody working with project management, not only software.

Advertisements