Robert Glass: Facts and Fallacies of Software Engineering
2003, Pearson Education, ISBN 0-321-11742-5, 195 pages
reviewed by Conrad Weisert, February, 2003
This is another one of those collections of independent short articles. You can read it straight through in one sitting or you can browse through the six dozen items for topics of immediate interest. The style is friendly and easily understood.
Although little of the content will surprise mature professionals, its publication is timely, given the current interest in "silver bullet" methodologies. The Foreword by Alan Davis aptly characterizes some of their promoters as "pundits of the perfunctory".
As Professor Glass persuasively reminds us, software quality, programming productivity, and project manageability are influenced more strongly by common-sense good practices than by fads. I particularly relished fact 47:
"Quality is not user satisfaction, meeting requirements, meeting cost and schedule targets, or reliability." (p. 132)
The author goes on to recognize the recent shift in the meaning of software quality to mean just freedom from defects, an issue this web site has been complaining about since our issue of the month back in May, 1999, and most recently just last month (January, 2003).
Fifty-five of the short articles are about some "fact", while only ten cite some "fallacy", that is some bit of folklore that has become so widely quoted and accepted that many managers and practitioners believe it. Here's fallacy 1:
"You can't manage what you can't measure." (p. 155)
As the author points out, we do so all the time.
One of Professor Glass's facts is really a fallacy:
"Software estimates are rarely adjusted as the project proceeds."
A fundamental property of the phased life cycle, is the end-of-phase funding review. Before starting each phase we re-estimate the rest of the project, and may re-eveluate the return-on-investment justification. That's what the life cycle is about.
If there's a weak point in Professor Glass's new book, it's his naive but nevertheless vigorously stated views on programming languages. Readers of ACM Communications already know of his staunch defense of COBOL. He introduces the topic (fact 30):
"COBOL is a very bad language, but all the others (for business applications) are so much worse." (p. 87)
He correctly points out that much of the sneering condescension directed at COBOL by the "Java community" and others is unjustified and ill-informed. Misdirected criticisms, however, won't make a flawed language into a good one. Many informed experts would assert this:
"COBOL isn't nearly as bad as its critics claim, but it's still pretty awful."
A programming language's merit1 is less determined by its origins and its reception than by the ease with which programmers using it can develop and maintain software. COBOL is notorious for unmaintainable nightmares, due in part to shortcomings seldom cited by either its partisans or its younger critics.
Knowlegeable advocates of either PL/I or C will be astonished, probably even infuriated, by Professor Glass's claim that "PL/I set the pattern for the Pascals and Modulas and Cs and Javas to come." Indeed it's hard to imagine two procedural programming languages more utterly different in their underlying "pattern" than PL/I and C, but I suppose Glass is entitled to his opinion.
Professor Glass, however, is not entitled to this error:
"For the decimal arithmetic feature it [COBOL] provided the penny-accurate calculations so essential to accountants and so impossible with most other numeric formats including floating-point." (p. 88)
The C++ Money class on this web site, for example, provides penny-accurate calculations. It uses an internal floating-point representation.
Those are minor flaws in an otherwise worthy contribution by Robert Glass.
Return to book reviews.
Return to table of contents.