After a brief introduction, Bell and Evans’s Mastering documentation is divided into five parts. “Getting Started,” the first part, provides the exposition of the authors’ viewpoints and strategies for documenting systems. This material explains their strategy of document standardization, updating and tracking methods, and the relationship of documentation to the project life cycle.

The subsequent four parts of the book are entitled “Specifying the System,” “Controlling the Project,” “Developing the System,” and “Delivering the System,” and take up approximately 120 pages. They form the bulk of the volume and contain “fill in the blanks” format sample documentation standards, or what the authors call “Document Masters.” Herein lies both the strength and the weakness of this book.

I will certainly join with Bell and Evans in their unspoken feeling (undoubtedly a motivation for the book) that there is a lack of hands-on guidance for practitioners in computer technology and information systems [1]. It is clear that this book on documentation is aimed at those who have to do it, and not at university students taking a technical writing course. The outreach to practitioners is laudable; however, practitioners do not need fluff. Many of the pages of “document masters” are white space, several having only a few lines of type or only 50–60 percent filled in. In spite of repeated exhortations to create documentation standards, the authors use a non-standard description of the development life cycle (p. 4). Graphic models such as dataflow diagrams are not discussed as part of documentation. An appendix on punctuation rules is surprising: certainly, practitioners have more complete sources for this kind of reference.

I found the 82-page Part 1 the most interesting and useful. Technical writers I know would surely be piqued to thought by many of the opinions introduced by Bell and Evans. Would only that they had given this section more attention and expanded it into a book in its own right. For example, the introduction mentions the role of a “document controller,” a team member responsible for enforcing standards, version control, and completeness. This important team member is never mentioned again and is not included in the index. The remaining four sections of the book could have been reduced to an appendix. An example of roff input and output is out of place in a work such as this, especially since desktop publishing tools (Ventura, Pagemaker, MacWrite/Paint, etc.) are not dealt with in any depth. Some of the managerial discussion must be tongue-in-cheek. For example, in discussing a method for calculating the total number of weeks needed for documentation, we are told to simply “total the weeks needed for each document” and then “divide by the number of . . . staff available” (p. 66). Do the authors think the coordination of growing numbers of writers takes no time? Surely most managers have left them behind here.

In summary, this book is an attempt to reach the documentation professional with some thoughts and guidance based on actual experience. An experienced documentor, however, will not find enough depth to the discussion, and for this reason the book is not suitable for academic technical writing courses. For inexperienced documentors, the book may provide material for thought, and perhaps for action. For this audience, I would recommend a look.