I found this book very entertaining, especially since I read it right after I had finished a review of Derrick [1]. Both authors use an informal, humorous writing style to convey their messages. Both works are how-to books and try to provide the reader with step-by-step hints as to how to approach important topics in computing.

Brinkworth states that his primary purpose in writing the book is to “restate what is good practice in software quality management,” and he does this effectively and concisely. More important, in the last chapter he finally articulates the substance of the book, “to give the reader various approaches to management that will yield a high quality system.” I thus feel that the book would have been better titled System quality management, since the emphasis is on quality and systems, two important concepts that are used throughout the book and that the author takes pains to define in the first few chapters. Brinkworth attempts to talk about software quality, especially in the chapter on coding, but to be a book on software quality, this work should have walked the reader through a specific software development project.

The chapters are typical of a systems analysis book with special emphasis on the management aspect of areas such as coding, testing, installation, and supporting a live system. The chapter on coding emphasizes guidelines and processes that could turn all of this work into fun instead of drudgery. Chapter 5 takes a look at testing, not as a wimpy activity where everything is accepted cordially, but as an activity that actually subjects a system to various rigors that will ultimately lead to the one true gauge of a successful test--that a bug has been found.

Chapter 6 captures the various components of installing a system, which could take a full 18 months. The author cautions that a fallback position should always be available for that one time when things go wrong. He also emphasizes that a change to a new system is not complete without training--many an organization has forgotten that the users will ultimately determine whether a new system is going to succeed. One aspect of the book that I agree with is its user orientation. Many a system has been set up because the administrators and computing center people thought it was a good idea without thinking of the users, who are always the last to know about the change. Thus, aside from thinking about hardware and software, the author emphasizes “liveware,” his term for the people who use the system.

I especially enjoyed the chapter on documentation. I am somewhat of a docuphile, as Brinkworth calls those who love documentation, as distinct from docuphobes, who shun documentation. He suggests that most programmers have to make the leap from programming as a game, which for most high school and college programmers produces sloppy documentation, to programming as a business, which requires an understanding of the value of the software in the overall scheme of an organization’s activities. Thus, the author stresses the importance of documentation. Like Brinkworth, I believe in providing step-by-step instructions to users who sometimes do not have the necessary background to find their way around the system should they get lost in undertaking a task. The same applies to programmers who inherit the task of revising a program to accommodate the expansion or changing needs of an organization. A lot of time, effort, and expense can be avoided by proper documentation, which helps the next user or programmer figure out how to modify the program.

I am unsure of the book’s basic purpose. It has some of the components of a systems analysis text, but because of its length, it obviously does not contain all that a 300-plus-page systems analysis text usually contains. It tries to ask provocative questions at the end of each chapter. In professing to be proactive, the author urges users to deviate from the usual linear thinking. (Do not read the book chapter by chapter. Peruse the book depending on the stage of the system software development process you are in. Use lateral thinking.) Therefore, I would use it as supplementary material in a systems analysis class. It would be valuable as a way of summarizing what students may learn if it is read before the main text or restating what they may have learned if it is read afterwards.

Brinkworth uses a lot of acronyms, which facilitates the flow of the material but sometimes became overwhelming since one had to be well-versed in many acronyms. The glossary at the end of the text and the thorough index were helpful in deciphering all of these terms.

The author admits to using a word processor. I doubt that he made use of the spell-checking utility of his software package, however, because of the proliferation of typographical errors.

The author tries to bridge theory and practice with his academic asides, with references to various relevant works, and with the use of the works of Deming, Juran, and Crosby in his discussion of quality. Familiarity with some of the academic background is helpful in placing this work in the context of various attempts to emphasize system quality.

In the final analysis, Brinkworth acknowledges that change in a company’s system orientation for the sake of change may not be useful and therefore suggests the use of change control. At the same time, he admonishes that not to decide constitutes a decision and that one’s inaction can be construed as action, which precludes one from having any say about the results of choices that have been made.

I enjoyed the book because I am no longer a serious programmer. I recommend that serious programmers read the book in order to understand the importance of the quality of their work to the system within which they operate. This work provides an essential, oft-forgotten lesson: that implementing hardware and software changes in any environment requires thinking about their effects on people.