ACCU Home page ACCU Conference Page
Search Contact us ACCU at Flickr ACCU at GitHib ACCU at Facebook ACCU at Linked-in ACCU at Twitter Skip Navigation

Search in Book Reviews

The ACCU passes on review copies of computer books to its members for them to review. The result is a large, high quality collection of book reviews by programmers, for programmers. Currently there are 1949 reviews in the database and more every month.
Search is a simple string search in either book title or book author. The full text search is a search of the text of the review.
    View all alphabetically
Title:
Facts and Fallacies of Software Engineering
Author:
Robert L. Glass
ISBN:
0-321-11742-5
Publisher:
Addison-Wesley
Pages:
195pp
Price:
£22-99
Reviewer:
Francis Glassborow
Subject:
engineering
Appeared in:
14-6
This is the latest title from a well-known author in this subject area. Alan Davis has this to say in his brief Foreword:

Bob has had a history of providing us with short treatises on the many software disasters that have occurred over the years. I have been waiting for him to distil the common elements from these disasters so that we can benefit more easily from his many experiences. The 55 facts that Bob Glass discusses in this wonderful book are not just conjectures on his part. They are exactly what I have been waiting for: the wisdom gained by the author by examining in detail the hundreds of cases he has written about in the past.

In the first four chapters (About Management, About the Life Cycle, About Quality and About Research) Robert Glass presents 55 'facts'. Each is presented with a single sentence introduction (e.g. fact 7: Software developers talk a lot about tools, but seldom use them.) Under that heading you will find four sections: Discussion, Controversy, Sources and References.

The final three chapters (About Management, About the Life Cycle, and About Education) present 10 fallacies (for example, fallacy 3: Programming can and should be egoless. and fallacy 10: You teach people how to program by showing them how to write programs.) are presented in a similar format.

The author has a comfortable writing style that makes it easy to read and understand. Of course, the main reason for writing a book such as this one is that much of the content will be considered controversial by many of its potential readers. I never advocate thoughtless reading of technical books, and that includes thoughtless rejection as well as acceptance.

The biggest problem is that different items in this book are addressed to different participants. By that I mean that the people who have the power to respond to them vary from managers, through system architects and programmers to educators. This means that the individual reader is only in a position to respond to parts of the book. I hope that many of you will read the whole of this book but not then proceed on the basis that you are OK and what really needs fixing is the work of other types of participant.

This is a book that deserves to be widely read by participants in software development, and then discussed, understood and acted upon.Non-Programming