Facts and Fallacies of Software Engineering

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 ReadGlass’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-StructuredThink 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 ImpactfulThis 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 FactA 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.ConclusionOverall, 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.

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

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!

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.

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...

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