Facts and Fallacies of Software Engineering (Agile Software Development)

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!

This book gets 4 stars for being pleasant to read, well-structured, and efficiently impactful. I would have liked to see more studies supporting the facts and fallacies. A more accurate title for this book might be “55 Opinions and Fallacies Which are Probably Mostly Supported by Evidence”. Since Glass has a ton of industry experience, academic experience, and he’s written 25+ books it’s probably safe to accept his opinions for facts. He is very aware that some facts and fallacies will be controversial and addresses those dissenting opinions. The book also feels a little naive at times as it seems to argue that a lot of problems in software engineering are the result of management just not understanding engineering. I agree management could benefit by being more understanding of engineers, but it goes both ways and I think engineers need to be much more understanding of the realities of running a business. The number one takeaway from this book is how valuable it is to be able to bridge the gap between engineering and management. If you are able to do that, and do it well, you will be extremely impactful in an organization. Pleasant to Read Glass’s personality comes through in his writing which makes the book feel less academic and more fun to read (he is known as the “premier curmudgeon” of software practice). The writing is informal, but gets right to the point. Also, the book is succinct and moves along pretty quickly – each fact or fallacy only covers a couple of pages. Well-Structured Think of this book more like a table of contents. Each fact or fallacy is quickly summarized with a discussion and controversy. Then Glass provides references and sources if you want to look further. A lot of the sources are his own books. A lot of the sources are well-regarded books like the Mythical Man Month, Peopleware, and Refactoring. Efficiently Impactful This book gets right to the point which means you can read it fast, and still get a lot out of it. I found myself agreeing with most of the facts and fallacies, disagreeing with a few, and being surprised by a few new ideas. I learned the most from the sections about estimation and maintenance. I also loved his opinion that we should teach new programmers to program by having them read programs (not write them). More Opinion than Fact A lot of the so-called “facts” feel more like opinions. But they are probably right, so it doesn’t matter much. Regardless, it would be nice to see more studies backing up the facts. For example, the fact that “For every 25 percent increase in problem complexity, there is a 100 percent increase in solution complexity” is a pretty extraordinary claim. It seems like it’s probably true-ish, but it seems too clean-cut to be true. How can this be true in every setting? Another one is “Enhancements represent roughly 60 percent of maintenance costs.” Is this really true? And how many studies have replicated these results? You’d need to go and do the due diligence to be sure. Conclusion Overall, I highly recommend this book for software engineers and managers of software engineers. It is a quick read and will have an immediate pay-off. If you learn one thing from this book it is the importance of being able to explain to management why things should be done a certain way. If you can explain the why and explain it well you will have happy managers and happy engineers.

I bought this book based on a recommendation from a co-worker. I have not been disappointed. It is an easy read but it also makes you think. This will not be for everyone because his opinions are somewhat unique at times. However, it really helps any engineer consider what we do and how we do it. I am happy I read it and will read it again.

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 already knows. If you're just learning to program, or haven't done it for years yet, then I would increase my rating to four stars.

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.

Facts and Fallacies of Software Engineering is a strong read presented in an organized, concise manner that only a software engineering practitioner can do. Here you may learn a few things, or you may find yourself thinking "I knew that... I just forgot!" The author brings many years of experience to bear to discuss software engineering practices, quality, software management, and more. An excellent read.

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

The author is very opinionated and he makes that clear. He is very well experienced with lots of wisdom and is highly regarded. Even if you don't agree with him, you will better understand the issues as he explains his reasoning very well.

This book is an excellent diversion from reading text books or doing normal work, but it's conclusions are still highly valid for any project. I found it a humourous read, and for virtually every point made I found my self nodding in agreement. I highly recommend lending the book to your boss prior to a personal appraisal, as the first two points are about how worthy good developers are! Any software developer should get this book for a bit of light reading, and bring back those memories of past project disasters!

Nice work! If you are keen on the history of software engineering ! Experiences shared are useful and lasting.

The reason why I am nothing throwing in all 5 stars is that the books style irritates me a little. I would rather have all the references and sources in an appendix in the end of the book, rather than after each fact & fallacy. But that said, the f&f that is shown here are good to be reminded of for almost any programmer. I wonder a bit why a fact stating that COBOL is the best business computer language is needed - true that it may be it is irrelevant and carries not the same weight as other statements in the book (I could add another fact about SNOBOL being the best string-manipulating language etc., but whats the relevance...?). The book is part of the eXtreme / pragmatic / agile programming paradigme that we see these years. And true is it that Robert L. Glass doesn't bring that much new stuff - he is referring to his own old books a lot of the time - but from personal experience I have already seen that managers are impressed by the facts stated here. So after all: The book should be used to throw in a couple of facts in an argument with a manager. That, or Dilbert...

This is a great book founded in common sense, real life experience and genuine evidence. Most of the rest of the field of software engineering literature is characterised by idealogues and snake oil salesmen. This is the best cure to snake oil.