Browse Books

Reviewer: James W. Moore

Having achieved notable recognition writing about object-oriented development methodology, Booch tries his pen at explaining how to manage an object-oriented project. This book is intended to address the issues of management “by offering pragmatic advice on the recommended practices [136 of them] and rules of thumb [79] used by successful projects.” It is directed to project managers and senior programmers, and is based on Boochs experience in “hundreds of projects.” The book is organized into seven chapters: First Principles Products and Processes The Macro Process The Micro Process The Development Team Management and Planning Special Topics Back matter includes an index, a glossary, a well-selected bibliography of 30 entries, and summaries of the recommended practices and rules of thumb (which would have been more helpful had they been cross-referenced to the body of the text). The tone of the text is a bit condescending. It is full of terms such as “brutal,” “ruthless,” and “rabid prototyping,” perhaps in an attempt to appeal to an assumed audience of managers who base their decisions on football metaphors. The foci of the book are the companion descriptions of the “macro” (management) process and the “micro” (technical) process. I found the chapter on the macro process to be informative but tedious. It is subdivided into five major phases, and for each phase, is divided into five sections: purpose, products, activities, agents, and milestones and measurements. The organization tempts the author to excessive repetition, leading ultimately to the readers boredom and disorientation. In contrast, the chapters on the micro process and special topics are notably concise. Ultimately, the value of a book like this is measured in terms of the quality of its advice, and some of that advice is excellent. For example, the section on architecture provides superb advice regarding emphasis on structural mechanisms, and the material on prototyping properly emphasizes the pursuit of goals carefully defined in advance. Unfortunately, too much of the management advice is facile, superficial, or even damaging. This is a particularly egregious sin in a book upon which readers will rely to determine whether to abandon instincts that were previously effective but are now rendered inappropriate in the context of a new technology. Among the advice, there are truisms—“what is to be avoided is gratuitous documentation”; stereotypes—“programmers left to their own devices never reach closure”; and dangerous pop psychology—“Watch the conduct of CRC card exercises. Your good abstractionists will tend to really engage with these kinds of exercises, but the poor ones will tend to sit back and show distinct apathy.” Even some of the technical advice must be taken with a grain of salt because of self-selection in the authors scope of experience. For example, it might be regarded as a significant claim that “o f the successful projects I came across, far more of them use object-oriented technology than do not.” Later, when the reader finds the surprising comment that “a good requirements document is inherently object-oriented,” one must suspect that both claims are simply reflections of a nearly exclusive immersion by the author in object-oriented projects. Furthermore, I was a little alarmed to learn that, aside from quarterly two-day architectural reviews, reviews should be scheduled “as needed” for only an hour in duration, with the consequence that it is “simply impossible to review every line of code.” On the other hand, informal “bug hunts” are encouraged. One is forced to wonder at the quality and cost-effectiveness of this approach and its implications for mentorship and process improvement. In short, I was left with the impression of a wonderfully flawed book, one that combines the authors superb and deep insights into object-oriented development methods with a superficial, perhaps even cynical, view of management methods.