Customer Reviews


38 Reviews
5 star:
 (22)
4 star:
 (10)
3 star:
 (4)
2 star:
 (1)
1 star:
 (1)
 
 
 
 
 
Average Customer Review
Share your thoughts with other customers
Create your own review
 
 

The most helpful favorable review
The most helpful critical review


87 of 89 people found the following review helpful
5.0 out of 5 stars A valuable and easy to read summary of the state of the art
I have read a fair number of software engineering books, and this is one of the more enjoyable books that I have read. When I first heard about it, I thought the concept of a sort of summary of the state of the art sounded really interesting. Although I haven't read any of the author's previous books, I have read and enjoyed his columns in IEEE Software and Communications...
Published on December 16, 2002 by Henrik Warne

versus
4 of 5 people found the following review helpful
3.0 out of 5 stars No real new knowledge
I suppose this book would be good for someone trying to convince their management not to make silly mistakes, but as a practicing engineer who writes code for a living, there wasn't much new here for me. It's not a bad book by any means, and the lessons it teaches are worth remembering, but they are all things that anyone who has written significant amounts of software...
Published 19 months ago by James S. Keane


‹ Previous | 1 2 3 4 | Next ›
Most Helpful First | Newest First

87 of 89 people found the following review helpful
5.0 out of 5 stars A valuable and easy to read summary of the state of the art, December 16, 2002
This review is from: Facts and Fallacies of Software Engineering (Paperback)
I have read a fair number of software engineering books, and this is one of the more enjoyable books that I have read. When I first heard about it, I thought the concept of a sort of summary of the state of the art sounded really interesting. Although I haven't read any of the author's previous books, I have read and enjoyed his columns in IEEE Software and Communications of the ACM, so I had high hopes about this book. And I wasn't disappointed.
Facts and Fallacies of Software Engineering is divided into 55 facts and 10 fallacies. Each fact and fallacy is presented in the same way. There is a headline/slogan that summarizes it, usually one or two pages of Discussion giving more details, then a Controversy section describing what (if anything) people disagree about and finally Sources and References.
The 55 Facts are divided into the following sections and sub-sections: Management (People, Tools and Techniques, Estimation, Reuse, Complexity), Life Cycle (Requirements, Design, Coding, Error Removal, Testing, Reviews and Inspections, Maintenance), Quality (Quality, Reliability, Efficiency) and Research.
The 10 Fallacies are divided into Management, Life Cycle and Education.
This way of organizing the material works really well, and makes the book very accessible and easy to read. It also allows you to jump around and read what interests you the most first (which is what I did, although I eventually read all of it).
Many of the facts are well known (for example Fact 3 "Adding people to a late project makes it later", Fact 16 "Reuse-in-the-large remains a mostly unsolved problem" and Fact 24 "Requirement errors are the most expensive to fix during production"), but that doesn't matter. It is actually good to be reminded of these facts even if you already know them, and the author does a very good job of summarizing them.
Another thing I like about the book is the Sources and Reference parts (although I think they might as well have been combined into just one Reference section). Often there are references to research papers where the original fact was presented. It is nice to know that what is presented as a fact is indeed a fact that has been validated by research, and not just the opinion of the author (although there is certainly room for opinions in a lot of places as well).
There are also lots of references to other books on software engineering, and a lot of the classic books (like The Mythical Man-Month, Peopleware and Design Patterns) are referenced. So there is plenty of leads in case you want to find out more about a certain fact.
Among the facts I liked the most were Fact 12, Fact 21 and Fact 26.
Fact 12: "Since estimates are so faulty, there is little reason to be concerned when software projects do not meet estimated targets. But everyone is concerned anyway". This fact and the related ones simply state that when a project is late, it is very likely because the estimated time to complete it was unrealistic. Very true.
Fact 21: "For every 25 percent increase in problem complexity, there is a 100 percent increase in complexity of the software solution." I had never seen this fact before, but it does ring true to me. And as the author writes, it explains a lot of the other facts in the book as well.
Fact 26: "Explicit requirements 'explode' as implicit (design) requirements for a solution evolve". In other words, each explicit requirement leads to many more implicit requirements (by a factor of up to 50). This too I had never seen stated, but I definitely recognize this from my own experience.
The Fallacies section list ten common misunderstandings in software engineering, and this is where I disagree on a couple of points. Fallacy 7 states "Random test input is a good way to optimize testing". I agree that it can not be the only test approach, but since he also writes "It may or may not survive as a test approach", he is skeptical to it in general. My own experience is that it is an invaluable complement that helps flush out numerous what I call "timing dependent" bugs caused by the nature of asynchronous events.
I also don't think all his arguments in Fallacy 8 are valid. I agree that since there is no data demonstrating the truth of "Given enough eyeballs, all bugs are shallow", we should not just accept it as truth. But I think he misses the point when he refers to research showing that inspections don't get much extra benefit beyond 2 to 4 participants. My interpretation is that the "enough eyeballs" are not so much inspecting the software in question as running it and debugging it when there is a problem. And the "all bugs are shallow" should not be interpreted too literally. Of course the bugs may still be difficult, but if many people look at it, the chances of someone solving it fairly quickly increases.
Those two examples notwithstanding, I did find myself nodding my head and saying "yes, I agree with that" almost all of the time reading this book.
There are many more interesting facts that I have not commented on, and if you are interested in software engineering I highly recommend this book.
Help other customers find the most helpful reviews 
Was this review helpful to you? Yes No


33 of 33 people found the following review helpful
5.0 out of 5 stars Insightful To The New Manager/Team Leader, April 4, 2003
This review is from: Facts and Fallacies of Software Engineering (Paperback)
The other reviewers have done a fine job of covering the content of the book. I will comment about its usefulness. In short, this book is truly valuable to the developer who has recently been promoted to team leader. While developers would benefit greatly from this book, the reality is that most developers would rather read books like "Effective C++", "Design Patterns", "Expert One on One Oracle", etc. To the new manager, though, this book is a gem. The book talks about specific management issues as well as the development life cycle and quality. In short, the book focuses exactly on what the team leader does and the team leader's team. In addition to the material presented in the book, the author gives a great number of sources and reference for further reading.
Help other customers find the most helpful reviews 
Was this review helpful to you? Yes No


13 of 15 people found the following review helpful
5.0 out of 5 stars Good summary of Software Engineering ideas and trends, February 28, 2003
By 
This review is from: Facts and Fallacies of Software Engineering (Paperback)
Written in the style of "Effective */More Effective *", this book presents what the author asserts are 55 facts about software engineering.
While you will see the obligatory "Adding people to a late project makes it later" section, the book also introduces several 'facts' that I have never really thought much about e.g. "Enhancements represent roughly 60 percent of maintenance costs"
The true gems of this book are the 'source' and 'reference' section of each fact. Their purposes are twofold. Firstly, they serve to validate the author's claim for each of these facts. Secondly, they provide readers with good follow-ups.
Amazingly, many if not most of the software classic are somehow mentioned in this book. (Even the cult classic Zen and the Art of Motorcycle Maintenance!)
This book manages to capture most of the essence of software engineering literature of today. Certainly, you may not agree with what the author terms as facts. The author does attempt to address these issues under 'Controversy' for each fact.
If you read this book, be sure to follow up on your reading with one of the many mentioned articles/books. Otherwise, you could potentially be left with only a surface understanding of the many issues involved.
Fact 56: "This reviews is written from the viewpoint of a 4 year old software developer in Singapore"
Help other customers find the most helpful reviews 
Was this review helpful to you? Yes No


9 of 10 people found the following review helpful
5.0 out of 5 stars (Not so) common wisdom about building software, December 2, 2002
This review is from: Facts and Fallacies of Software Engineering (Paperback)
Bob Glass is a programmers' programmer -- he's at the other end of the scale from software engineering gurus. This collection of fifty-five software facts and ten fallacies is distilled from his forty-five years of programming experience. Much of it is the kind of thing your grandmother could have told you -- if your grandmother was a programmer -- but some items will surprise and others annoy some people.
Take the following two items as examples:
"The 60/60 rule: 60 percent of software's dollar is spent on maintenance, and 60 percent of that maintenance is enhancement."
"Understanding the existing product consumes roughly 30 percent of the total maintenance time."
That implies that one of the most valuable skills you can teach a Computer Science student is how to *read* code. But as Glass points out (and he taught graduate students for a while) CS courses only teach students to *write* programs, and then they don't often grade the code on readability.
The section on design, which Glass describes as the most intellectual phase of a software project, is the best description of how software designers actually work that I've ever read. He claims that top-ranked designers routinely ignore or subvert the methodologies used by their shops in order to do the job the right way. He has an especial warning for anyone trying to develop anything other than the most trivial program using XP.
The ten fallacies may have taken some well-known quotes out of context. Surely Eric Raymond of the open source movement didn't really mean, "Given enough eyes all bugs are shallow", to be taken literally. Either way, the point Glass is trying to make is that, without proof, we shouldn't *assume* that open source code is less buggy than proprietary code.
Facts and Fallacies of Software Engineering is aimed at two audiences: those without Glass' 45 years of programming experience, and those who have it but, like all good professionals, want to refresh the basics. Since some of the wisdom came with useful statistics that I've never seen published before, I'd recommend the book to anyone involved in developing or maintaining software.
Help other customers find the most helpful reviews 
Was this review helpful to you? Yes No


4 of 4 people found the following review helpful
5.0 out of 5 stars Against common wisdom, November 4, 2005
By 
Ugo Cei (Pavia, PV Italy) - See all my reviews
(REAL NAME)   
Verified Purchase(What's this?)
This review is from: Facts and Fallacies of Software Engineering (Paperback)
Here's another short book (195 pages) that cannot be missing from a good software engineer's personal library. Robert L. Glass condenses in 55 facts and 10 fallacies - some of them well known, others more controversial - his vast knowledge of the field.

The 55 facts are subdivided into four main sections:

1. About management

2. About the Life Cycle

3. About Quality

4. About Research

The ten fallacies are instead grouped as follows:

1. About Management

2. About the Life Cycle

3. About Education

This organization could provide a hint as to what sections of the book you'd better read first if you are managing programmers rather than if you're more involved in coding. But in any case, I suggest that whatever your positions, you will be better served by reading it all.

Glass, a member of the "old guard" of software engineering, having been a practitioner of the field since its very beginnings, is a bit wary of espousing the latest trends in software, like eXtreme Programming. Some of his facts and fallacies fly right in the face of some XP principles and practices. See for instance fallacy nr. 3:

Programming can and should be egoless.

How can you reconcile this with collective code ownership and pair programming?. In other instances, he shares some of XP's convictions. See for instance fact 28:

Design is a complex, iterative process. Initial design solutions are usually wrong and certainly not optimal.

In the end, no matter what development process you like best, you're bound to find some controversial statements inside this book. If this makes you think about what you're doing and how successful you're being at it, I think the book will have fulfilled its purpose. By being apparently dogmatic in its format (what sounds more dogmatic than a list of asserted "facts"?) Glass manages to teach us that what you should be avoiding mostly is indeed dogma. In the current climate, dogma typically takes the form of a new development methodology that promises to end all debates on methodology. To fight this, everyone should memorize fallacy 5:

Software needs more methodologies.

Highly recommended!
Help other customers find the most helpful reviews 
Was this review helpful to you? Yes No


6 of 7 people found the following review helpful
4.0 out of 5 stars Lots of good starting points, December 9, 2004
Verified Purchase(What's this?)
This review is from: Facts and Fallacies of Software Engineering (Paperback)
Glass is an opinionated old coot, not afraid to speak his mind no matter what the source of the silliness he sees around him. These aren't the deepest thoughts on the business, craft, and engineering of software, but they cover a lot of important ground. Best, these aphorisms come from hard-won experience in many areas. I don't disagree with any of them, but I have to qualify my agreement in a few places.

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.

//wiredweird
Help other customers find the most helpful reviews 
Was this review helpful to you? Yes No


4 of 4 people found the following review helpful
5.0 out of 5 stars Insightful and Painful, May 2, 2008
By 
Verified Purchase(What's this?)
This review is from: Facts and Fallacies of Software Engineering (Paperback)
This book covers all the mistakes we know about, but keep on making regardless.

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!
Help other customers find the most helpful reviews 
Was this review helpful to you? Yes No


3 of 3 people found the following review helpful
4.0 out of 5 stars Must-read, but take it with a grain of salf, August 10, 2010
By 
Egor Shipovalov (London, United Kingdom) - See all my reviews
(REAL NAME)   
This review is from: Facts and Fallacies of Software Engineering (Paperback)
Author does a very good job at debunking common myths of software development, especially those most popular with people not involved in development process directly. However, his attitude towards opponents and lack of objectivity in the fact base render his account somewhat less persuasive than it, in my opinion, could be. I would still recommend this book to any project manager of customer willing to improve their understanding of software development. There are not too many books that do a decent job at it and are short enough.
Help other customers find the most helpful reviews 
Was this review helpful to you? Yes No


2 of 2 people found the following review helpful
5.0 out of 5 stars Easy to read, Great references, Makes you think, October 28, 2005
Verified Purchase(What's this?)
This review is from: Facts and Fallacies of Software Engineering (Paperback)
A wonderful collection of facts and fallacies about software engineering. The references for each topic are outstanding, in fact, some of the topics piqued enough interest for me to order several of those books. The areas I found most interesting whether I agreed or disagreed were: software reuse, code review effectiveness, thoughts on new methodologies, and statistics on maintenance.

This book is easy to read and the content flows well from topic to topic. I highly recommend it for the richness of the references and for making one think about the different aspects of software engineering that are often overlooked.
Help other customers find the most helpful reviews 
Was this review helpful to you? Yes No


2 of 2 people found the following review helpful
4.0 out of 5 stars A Great Bathroom Reader, May 14, 2009
By 
This review is from: Facts and Fallacies of Software Engineering (Paperback)
I read this book with breakfast and supper, literally. The two to three page facts are conveniently bite-sized; this is a rare "bathroom reader" of a technical book.

I'm not trying to make light of the content: most of it is both interesting and insightful. Like his opinions or not, Glass backs up his ideas with hard data, which, as he comments himself, is sorely lacking in the field.

This book was published in 2002, but anyone caught thinking the facts are outdated is fooling themselves. Consumer-grade processors may be running three times faster (plus additional cores) than they were in 2002, but software development is far from being three times as refined.

Reading this book will make you feel more "in the know" regarding the realities of software development.
Help other customers find the most helpful reviews 
Was this review helpful to you? Yes No


‹ Previous | 1 2 3 4 | Next ›
Most Helpful First | Newest First

Details

Facts and Fallacies of Software Engineering
Facts and Fallacies of Software Engineering by Robert L. Glass (Paperback - November 7, 2002)
$44.99 $30.77
In Stock
Add to cart Add to wishlist
Search these reviews only
Rate and Discover Movies
Send us feedback How can we make Amazon Customer Reviews better for you? Let us know here.