(book review)
PROS:
This classic book remains a must read for programmers and managers to this day. It was first published in 1975, with 4 great new chapters added in the 1995 second edition. The short book is chock-full of practical wisdom coming from a computer scientist and manager with a ton of experience. I read it twice, about 10 years ago and again recently, and noticed that with additional experience, the book appears to be more relevant (usually a good sign).
My favorite propositions by Brooks [with my comments in brackets] are:
- Adding manpower to a late software project makes it later (a.k.a. Brooks's Law). Adding people to a software project increase the total effort necessary in three ways: the work and disruption of repartitioning itself, training the new people, and added intercommunication. Later research by Barry Boehm showed that hardly any projects succeed in less than 3/4 of the calculated optimum schedule, regardless of the number of people applied.
- More programming projects have gone awry for lack of calendar time than for all other causes combined.
- Schedule disaster, functional misfit, and system bugs all arise because the left hand doesn't know what the right hand is doing. Teams drift apart in assumptions.
- Productivity seems constant in terms of elementary statements. It may be increased as much as 5 times when a suitable high-level language is used. [This is supported by later research. According to Prechelt (2000), "Designing and writing the program in Perl, Python, Rexx, or Tcl takes only about half as much time as writing it in C, C++, or Java and the resulting program is only half as long." Obviously, high-level languages should be understood more broadly than simply programming languages, and should include the proper use of external libraries, frameworks, free and commercial packages, etc.]
- Very good professional programmers are ten times as productive as poor ones, at the same training and two-year experience level (data from Sackman, Grant and Erickson). [This difference is not fully reflected in programmers' salaries, and probably never will be, which enables enlightened managers to hire great programmers at bargain prices.]
- The barriers to effective dual-ladder organization [one ladder for technical experts, second ladder for managers] are sociological, and they must be fought with constant vigilance and energy.
CONS:
Some propositions from Brooks are more arguable than others. For example, Brooks states that every software system must have a chief architect or designer. Another arguable proposition is expressed in the chapter "No Silver Bullet". It states that within 10 years from the essay's publication in 1986 there will not be any single tool that increases the productivity of programmers by 10 fold.
A minor drawback of the book is the abundance of war stories with references to obsolete technology that are much harder to understand now than in 1975. Brooks often illustrates his general points that are still relevant today with specific references to obsolete languages such as Modula or Algol, old machines such as System/360 or IBM 7090, and the issues of simulating compiling of something truly ancient on a machine of only a historical interest. For a contemporary reader these references sometimes obscure, rather than help the main point Brooks is trying to make. The book would benefit from another edition adapted for modern readers, with some of these examples explained better, or replaced altogether with more generic examples.
The bottom line:
The Mythical Man-Month is a great book, and I only wish it were more widely read and understood.
No comments:
Post a Comment