BKMYMAMO.RVW 990502 "The Mythical Man-Month", Frederick P. Brooks Jr., 1995, 0-201-83595-9, U$24.69 %A Frederick P. Brooks Jr. %C P.O. Box 520, 26 Prince Andrew Place, Don Mills, Ontario M3C 2T8 %D 1995 %G 0-201-83595-9 %I Addison-Wesley Publishing Co. %O U$24.69 416-447-5101 fax: 416-443-0948 bkexpress@aw.com %P 308 p. %T "The Mythical Man-Month: 20th Anniversary Edition" Brooks' work on software management is a classic, but, even with a quarter million copies in print, it is more regarded than read. A great many can quote Brooks' Law ("Adding manpower to a late software project makes it later") without knowing that it was Brooks' who said it. Which is a pity. I can fully agree with the promotional literature that says Brooks' work is "timeless." On the "influential" side, however, I have my doubts. If Brooks' truly had the influence he deserved, we would have fewer late projects. Brooks was originally writing from his experiences as project manager for IBM's System/360, and later with OS/360. It is remarkable how well his ideas have stood the test of time. While today we would long for an operating system that was "bloated" to a mere 400K in size (and I still haven't figured out the "tables" that keep being referred to), the concepts outlined for project management are as sound today as when first set down. And the objections raised against sound management and documentation were as silly in 1975 as they are today. Chapter one outlines the joy of programming, and any creative work, and how tragically that joy can be drowned in the crush of a badly managed project. Brooks shows very clearly how work can, and cannot, be partitioned in chapter two. A very interesting method of structuring a project team is given in chapter three, slightly weakened by the ship and surgical analogies which do not fully hold up in programming: software project teams are never faced with immediate life and death decisions. The problem of abstracting all "interesting" work to team leaders is examined in chapter four. Chapter five notes a tendency to try to overcompensate for prior missed opportunities, leading to software bloat. Team communication is looked at two ways in chapters six and seven. Project estimation, in chapter eight, is shown to be a poorly practiced art. Software bloat is revisited in chapter nine, and documentation in ten. Chapter eleven notes something we have lost sight of in our reliance on demo software: it isn't meant to be a mere GUI shell, but a working system that we make all the mistakes on. The need for tools, outlined in chapter twelve, is well accepted today, but the insistence on common tools would pull more than a few programmers up short. Modularity, promoted in chapter thirteen, is also praised today--but not always used. Chapter fourteen has a very solid grasp of the reasons for project slip. Documentation, of the right sort, is reviewed in chapter fifteen, including an attack on the venerable flowchart. The preceding chapters are all essentially unchanged from the original 1975 edition. Chapter sixteen is Brooks' "No Silver Bullet" paper, wherein he opined (in 1986) that programming was an inherently complex and difficult task, and that no development in the next ten years would provide a productivity increase on the level of an order of magnitude. (It is interesting that Java was unleashed upon the world at the end of that ten year projection, but, three years later, it hasn't opened any programming floodgates either.) Brooks points out objections to "NSB" in chapter seventeen, and answers them. The first edition is recast in point form in chapter eighteen. Chapter nineteen analyses what was right and enduring in the initial material, and what was wrong in the first place. An enduring classic that deserves to be read and re-read. copyright Robert M. Slade, 1999 BKMYMAMO.RVW 990502