- Paperback: 224 pages
- Publisher: Addison-Wesley Professional; 1 edition (November 7, 2002)
- Language: English
- ISBN-10: 0321117425
- ISBN-13: 978-0321117427
- Product Dimensions: 7.2 x 0.6 x 9.1 inches
- Shipping Weight: 1.5 pounds (View shipping rates and policies)
- Average Customer Review: 43 customer reviews
- Amazon Best Sellers Rank: #361,801 in Books (See Top 100 in Books)
Enter your mobile number or email address below and we'll send you a link to download the free Kindle App. Then you can start reading Kindle books on your smartphone, tablet, or computer - no Kindle device required.
To get the free app, enter your mobile phone number.
Facts and Fallacies of Software Engineering 1st Edition
Use the Amazon App to scan ISBNs and compare prices.
All Books, All the Time
Read author interviews, book reviews, editors picks, and more at the Amazon Book Review. Read it now
Frequently bought together
Customers who bought this item also bought
From the Back Cover
The practice of building software is a "new kid on the block" technology. Though it may not seem this way for those who have been in the field for most of their careers, in the overall scheme of professions, software builders are relative "newbies." In the short history of the software field, a lot of facts have been identified, and a lot of fallacies promulgated. Those facts and fallacies are what this book is about. There's a problem with those facts-and, as you might imagine, those fallacies. Many of these fundamentally important facts are learned by a software engineer, but over the short lifespan of the software field, all too many of them have been forgotten. While reading "Facts and Fallacies of Software Engineering," you may experience moments of "Oh, yes, I had forgotten that," alongside some "Is that really true?" thoughts. The author of this book doesn't shy away from controversy. In fact, each of the facts and fallacies is accompanied by a discussion of whatever controversy envelops it. You may find yourself agreeing with a lot of the facts and fallacies, yet emotionally disturbed by a few of them! Whether you agree or disagree, you will learn why the author has been called "the premier curmudgeon of software practice." These facts and fallacies are fundamental to the software building field-forget or neglect them at your peril!
About the Author
Robert Glass is the founder of Computing Trends. He has written more than a dozen books on software engineering and on the lessons of computing failures. Robert is trusted by many as a leading authority on software engineering, especially by those who read his columns in Communications of the ACM and IEEE Software. Robert also publishes a newsletter, The Software Practitioner, and speaks frequently at software engineering events.
Top customer reviews
The topics in the book do not go into details, however Glass provides many references to articles of origin, controversy or discussion where you can delve deeper into each fact or fallacy.
As Glass emphatically indicates, it is possible that you are not agree with some of the topics , but that does not make them any less interesting. Sometimes it seems he need go deeper on the arguments, but you can search in the references for details.
In the book you will not find anything original or new. Basically it's a compilation of these facts and fallacies discussed by many authors over the last 30 years.
I really recomend this book, even if you have a notion of the facts and fallacies in the book. It worth reading and have a handy reference list when you want to go deeper or when you want to recommend someone to read a specific topic.
When it arrived in the mail, I was amazed by how small this book was. It's a short read, but every section is brilliantly distilled to the bare essentials.
I've worked on several different teams developing software. There was very little in this book that came as a surprise. Every point seemed obvious, though in many cases, I was amazed by the wealth of research that Glass was able to cite to make his points. From the bankruptcy of hypesters to the importance of a work environment, Glass states the obvious with compelling and refreshing clarity.
The "painful" part was realizing that at some point in my career, I've made almost every mistake he highlights.
I found the tongue in cheek nature of the writing to be a bit much at times. That is my only complaint, and it's not so bad as to be unreadable.
It probably won't make you a better programmer, but the knowledge in this book will provide magnificent insight into all the non-coding aspects of software development that we so often overlook. Human nature hasn't changed, and software will always be complex. The facts and fallacies he cites truly are fundamental, and will be with us forever.
This book has given me a vocabulary with which to confront the absurd that we see every day in the world of software. Hopefully, I can now be a part of the solution rather than a part of the problem. Thank you, Dr. Glass!
For example, #32: "It is nearly impossible to test software at the level of 100% of its logic paths." I'd go farther and say it's usually dangerous even to try. If some pointy-haired manager decides that more coverage is better, programmers will dutifully optimize that metric. Error recovery is hard to test, so they'll edit out the error recovery. Integrity checks may be hard to trigger, so the integrity checks have to go. Trust me, this is not an improvement.
Or #51: "Residual errors will always persist." No argument there. "The goal should be to minimize or eliminate severe errors." That's one good goal, but there are lots of systems where the goal should be to continue service in the presence of errors, via error recovery, some fail-soft state, or other means. Even perfect software may violate its contract in the presence of hardware errors: given a one-in-a-billion error rate and 3GHz clock, errors happen three times per second. Even at one-per-trllion, they happen every five minutes or so.
Also, #46, a prioritized list of "-ilities" that define quality. Of course I disagree with his or any order. Heck, in one system I worked on, four different subsystems had four different lists. Reliability was paramount in one area - software failure would have to be repaired by unsoldering and replacing a chip. Other subsystems variously emphasized speed, compiled code size, and user-friendliness. In the bulk of the system, maintainability was at the top of the list (a fifth different priority list).
Although I generally like the content and style, a few things might have strengthened the book. Glass' favorite author, based on citation counts, is Glass. He's good, but so are other authors. This book isn't really self-contained. Lots of discussions are cursory (and he sometimes points that out), requiring a lot more elaboration of his part or a lot of reference-chasing time on the reader's part, assuming the reader can find the references at all.
Still, this is a welcome comment on the current state of affairs in software development. His one point - if there is only one - is that it's the same state we were in back in the 70s. Only the buzzwords have really changed. That point I agree with.