Zero Defect Software (Mcgraw Hill Software Engineering Series) [Hardcover]

G. Gordon Schulmeyer (Author)

Book Description

Series: Mcgraw Hill Software Engineering Series | Publication Date: October 1990

This text reviews existing software development methods and the problems of zero-defect programs. It covers subjects such as manual and automated error detection, computer aided software engineering, artificial intelligence and software testing techniques.

Product Details

• Hardcover: 400 pages
• Publisher: Mcgraw-Hill (Tx); First Printing edition (October 1990)
• Language: English
• ISBN-10: 0070556636
• ISBN-13: 978-0070556638
• Product Dimensions: 8.8 x 6 x 1.3 inches
• Shipping Weight: 1.4 pounds
• Average Customer Review: 3.0 out of 5 stars  See all reviews (1 customer review)
• Amazon Best Sellers Rank: #3,120,051 in Books (See Top 100 in Books)

More About the Author

Discover books, learn about writers, read author blogs, and more.

Customer Reviews

Most Helpful Customer Reviews

3.0 out of 5 stars "Zero Software" is a more appropriate title, December 15, 2008

By 

Jay P. Vansanten - See all my reviews
(REAL NAME)   

This review is from: Zero Defect Software (Mcgraw Hill Software Engineering Series) (Hardcover)

This review is biased, and I'm trying to be generous in my rating, but also trying to stifle a chuckle as I write.

The author apparently has a good reputation in formal software quality management. And, it's no small effort to write a book, having tasted some of that process myself. And further, this is probably one of the first books on the market to address issues of software quality so it is likely more direct than subtle, more theoretical than practical. That said, "authorities" can have a pretty strong influence on the weak minded, with detrimental effect far beyond what would be considered their actual expertise.

When I picked this book up, a decade ago, it seemed a worthwhile investment of time. As a programmer, I'm always trying to improve the quality of my code.

The book seems well written. The points made sense. BUT, IN THE AUTHOR'S PLAN, APPLICATIONS ARE NOT COMPILED BY PROGRAMMERS, RATHER BY QA FOLKS.

I read that section of the book again to make sure that I'd read this correctly. When I discovered I had, I read no further. That seemed complete idiocy. Programmers make mistakes -- as all humans do. We like to be able to address the smaller, the obvious ones before passing material on down the testing chain. In this scenario, QA folks, whose primary skill is not development or debugging, are put in a position to make debugging their primary focus.

Sometime later, I read in one of the trade rags about a programming group whose management had implemented a system apparently based on these principles: all compilers were removed from developer systems. Development ground to a halt. Then, an enterprising programmer snuck his C compiler into the office. Suddenly, the development team was again making a bit of progress, and he attained a high status, particularly among his peers. However, his secret was found out. He was promptly fired.

There are likely other aspects of the book which are of value, I'm sure, though those are not clear at this distance. But, this one guideline is simply so boneheaded, it raises the question of the validity and soundness of other recommendations.

The book's audience is the management creating a system for software development. But, from a managerial perspective, the Capability Maturity Model, as outlined by Jones in a number of volumes, serves a intellectually broader range of systems in development. Gerry Weinberg is unparalleled in his analysis of the human dynamics in software dvelopment with a focus on delivering quality software. Steve McConnell in _Code Complete_ does a wonderful job of addressing quaility issues from the programmer's perspective. And, books on analysis -- such as DeMarco's classics, Davis' on Software Requirements, Rumbaugh, and more recent OO design and modelling works based on UML, help navigate the area where the bulk and by far most costly software defects occur -- not in programming, but in design and analysis.

If one's interest is nothing but QA then some of the author's more recent work may be a better guide. But, to divorce QA from the wider development process in a one-dimensional approach has significant risks, in my opinion.

Here's to you, Mr. Pointy Head Manager!

And, we're going to take away your Spell Checker!