The Mythical Man-Month by Frederick Brooks

In the 20th anniversary edition of The Mythical Man-Month, Frederick Brooks adds four chapters to re-evaluate some of the positions he made in 1975. This book is mentioned over and over in things I read, and so I decided to go see what makes it a classic for myself. I was quite impressed with the notion that many of Brooks' ideas and projections are dead-on, even today, well over 30 years after he wrote about them. Then again, he says himself that many of our problems are people problems, not technology problems, and I guess human history is condemned to repeat itself if we don't know what came before.

One projection is that there will be no "silver bullet" that offers orders-of-magnitude improvements in productivity. Another is his emphasis that for large systems, we need conceptual integrity, and to organize it, he proposes recursion of architects (layered levels of decreasing abstraction). Many readers of this book were surprised that it devotes more time to people issues than technical--but he says that is and remains the biggest challenge in software development.

Though I found the book a bit dry and out of date, it was worth a quick read for the simple reason that it holds so many ideas that are so strongly advocated by Agile practices, and others that are not. Consistent with agile--we must use a process that assures us that "one always has, at every stage in the process, a working system. I find that teams can grow much more complex entities in four months than they can build"; "conceptual integrity is the most important consideration in system design". Communication is critical--and exponentially more difficult with larger and larger teams. He advocates giving developers room to be creative, saying they need room for "invention and craftsmanship". I guess the craftsmanship/codesmith movement goes way back! Another great line is "whenever talents permit, senior people must... delight in building programs with their own hands". No arm-chair architects or managers in Brooks' world! He also believes in "done-done", in other words--"milestones musbe be concrete, specific, measureable...coding, for counterexample, is '90 percent finished', for half the total coding time. Debugging is '99 percent complete' most of the time...". Though stand-up meetings weren't called it at the time, he knew the wastes of "status-review" meetings, and started calling things problem-action meetings instead. He also states, in more archaic terms, that getting the Acceptance Tests [design] right is the hardest part of development.

Not part of the agile world, he advocates both small iterations or large deployments, depending on context; he's the one who states "the bearing of a child takes nine months, no matter how many women are assigned", he posits that a project gets to be one year late, one day at a time; he (quoting Harlan Mills) suggests the ideal team structure be modeled after a surgical team. He names the "second system effect" as tempting designers to add extra features and frills that they didn't have a chance to add in the first system--and as a result this becomes bloated and fails. I think I saw that effect when I was on the job in New York. Brooks also talks a lot about documentation... I think this has been obsoleted by the use of intent-revealing test-first coding. Another obsolete point is his statement to "plan to throw one away".

Brooks obviously read a lot in preparation for this book--accumulating benchmarks, such as when he proposes that system coding should only be around 1/6th of the schedule; that developer estimates are often 1/2 of the actual time because of meetings and other interruptions from coding the active project; that higher-level languages (and implicitly higher levels of abstraction) are the only thing that's come along that can offer orders-of-magnitude improvements in productivity.