- Amazon Student members save an additional 10% on Textbooks with promo code TEXTBOOK10. Enter code TEXTBOOK10 at checkout. Here's how (restrictions apply)
Facts and Fallacies of Software Engineering Paperback – Oct 28 2002
|New from||Used from|
Special Offers and Product Promotions
Customers Who Bought This Item Also Bought
No Kindle device required. Download one of the Free Kindle apps to start reading Kindle books on your smartphone, tablet, and computer.
To get the free app, enter your e-mail address or mobile phone number.
From the Inside Flap
This book is a collection of facts and fallacies about the subject of software engineering.Sounds boring, doesn’t it? A laundry list of facts and fallacies about building software doesn’t sound like the kind of thing you’d like to kick back and spend an hour or two with. But there’s something special about these facts and fallacies. They’re fundamental. And the truth that underlies them is frequently forgotten. In fact, that’s the underlying theme of this book. A lot of what we ought to know about building software we don’t, for one reason or another. And some of what we think we know is just plain wrong.
Who is the we in that previous paragraph? People who build software, of course. We seem to need to learn the same lessons over and over again, lessons that these facts—if remembered—might help us avoid. But by we I also mean people who do research about software. Some researchers get mired so deeply in theory that they miss some fundamentally important facts that might turn their theories upside-down.
So the audience for this book is anyone who’s interested in building software. Professionals, both technologists and their managers. Students. Faculty. Researchers. I think, he said immodestly, that there’s something in this book for all of you.
Originally, this book had a cumbersome, 13-word title: Fifty-Five Frequently Forgotten Fundamental Facts (and a Few Fallacies) about Software Engineering was, well, excessive—or at least those responsible for marketing this book thought so. So cooler heads prevailed. My publisher and I finally settled on Facts and Fallacies of Software Engineering. Crisp, clear—and considerably less colorful!
I had tried to shorten the original long title by nicknaming it the F-Book, noting the alliteration of all the letter Fs in the title. But my publisher objected, and I suppose I have to admit he was right. After all, the letter F is probably the only dirty letter in our alphabet (H and D have their advocates, also, but F seems to reach another level of dirtiness). So the F-Book this is not. (The fact that an early computer science book on compiler-writing was called the Dragon Book, for the sole reason that someone had I suppose arbitrarily put the picture of a dragon on its cover, didn’t cut any ice in this particular matter.)
But in my defense, I would like to say this: Each of those F-words was there for a purpose, to carry its weight in the gathering meaning of the title. The 55, of course, was just a gimmick. I aimed for 55 facts because that would add to the alliteration in the title. (Alan Davis’s wonderful book of 201 principles of software engineering was just as arbitrary in its striving for 201, I’ll bet.) But the rest of the Fs were carefully chosen.
Frequently forgotten? Because most of them are. There’s a lot of stuff in here that you will be able to say “oh, yeah, I remember that one” and then muse about why you forgot it over the years.
Fundamental? The primary reason for choosing this particular collection of facts is because all of them carry major significance in the software field. We may have forgotten many of them, but that doesn’t diminish their importance. In fact, if you’re still wondering whether to go on reading this book, the most important reason I can give you for continuing is that I strongly believe that, in this collection of facts, you will find the most fundamentally important knowledge in the software engineering field.
Facts? Oddly, this is probably the most controversial of the words in the title. You may not agree with all of the facts I have chosen here. You may even violently disagree with some of them. I personally believe that they all represent fact, but that doesn’t mean you have to.
A few fallacies? There are some sacred cows in the software field that I just couldn’t resist skewering! I suppose I have to admit that the things I call fallacies are things that others might call facts. But part of your fun in reading this book should be forming your own opinion on the things I call facts—and the things I call fallacies.
How about the age of these facts and fallacies? One reviewer of this book said that parts of it felt dated. Guilty as charged. For facts and fallacies to be forgotten frequently, they must have been around for awhile. There are plenty of golden oldies in this collection. But here I think you will find some facts and fallacies that will surprise you, as well—ideas that are “new” because you’re not familiar with them. The point of these facts and fallacies is not that they are aged. It’s that they are ageless.
In this part of the book, I want to introduce the facts that follow. The fallacies will have their own introduction later in the book. My idea of an introduction is to take one last trip through these 55 frequently forgotten fundamental facts and see how many of them track with all of those F-words. Putting on my objectivity hat, I have to admit that some of these facts aren’t all that forgotten.
- Twelve of the facts are simply little known. They haven’t been forgotten; many people haven’t heard of them. But they are, I would assert, fundamentally important.
- Eleven of them are pretty well accepted, but no one seems to act on them.
- Eight of them are accepted, but we don’t agree on how—or whether—to fix the problems they represent.
- Six of them are probably totally accepted by most people, with no controversy and little forgetting.
- Five of them, many people will flat-out disagree with.
- Five of them are accepted by many people, but a few wildly disagree, making them quite controversial.
That doesn’t add up to 55 because (a) some of the facts could fit into multiple categories, and (b) there were some trace presences of other categories, like “only vendors would disagree with this.” Rather than telling you which facts fit into which of those categories, I think I’ll let you form your own opinion about them.
There’s controversy galore in this book, as you can see. To help deal with that, following each discussion about a fact, I acknowledge the controversies surrounding it. I hope, by doing that, I will cover your viewpoint, whether it matches mine or not, and allow you to see where what you believe fits with what I believe.
Given the amount of controversy I’ve admitted to, it probably would be wise of me to tell you my credentials for selecting these facts and engaging in this controversy. (There’s a humorous bio in the back of the book, so here I’ll make it quick.) I’ve been in the software engineering field for over 45 years, mostly as a technical practitioner and researcher. I’ve written 25 books and more than 75 professional papers on the subject. I have regular columns in three of the leading journals in the field: The Practical Programmer in Communications of the ACM, The Loyal Opposition in IEEE Software, and Through a Glass, Darkly in ACM’s SIGMIS DATABASE. I’m known as a contrarian, and I have a plaque identifying me as the “Premier Curmudgeon of Software Practice” to prove it! You can count on me to question the unquestionable and, as I said earlier, to skewer a few sacred cows.
There’s one additional thing I’d like to say about these facts. I’ve already said that I carefully picked them to make sure they were all fundamental to the field. But for all my questioning about how many of them are really forgotten, nearly all of them represent knowledge that we fail to act on. Managers of practitioners make proclamations showing that they’ve forgotten or never heard of many of them. Software developers work in a world too constrained by their lack of knowledge of them. Researchers advocate things that they would realize are absurd if they were to consider them. I really do believe that there’s a rich learning experience—or a rich remembering experience—for those of you who choose to read on.
Now, before I turn you loose among the facts, I want to set some important expectations. In presenting these facts, in many cases, I am also identifying problems in the field. It is not my intention here to present solutions to those problems. This is a what-is book, not a how-to book. That’s important to me; what I want to achieve here is to bring these facts back into the open, where they can be freely discussed and progress toward acting on them can be made. I think that’s an important enough goal that I don’t want to dilute it by diverting the discussion to solutions. Solutions for the problems represented by these facts are often found in books and papers already published in our field: software engineering textbooks, specialty topic software engineering books, the leading software engineering journals, and software popular-press magazines (although there is profound ignorance mixed in with important information in many of these).To help with that quest, I present these facts in the following orchestrated structure:
- First, I discuss the fact.
- Then I present the controversies, if any, surrounding the fact.
- And finally, I present the sources of information regarding the fact, a bibliography of background and foreground information. Many of those sources are ancient, by software engineering standards (those are the frequently forgotten facts). Many are as fresh as tomorrow. Some are both.
I’ve aggregated my 55 facts into several categories: those that are
- About management
- About the life cycle
- About quality
- About research
The fallacies are aggregated similarly:
- About management
- About the life cycle
- About education
Ah, enough preparation. I hope you’ll enjoy the facts and fallacies I present here. And, more important, I hope you’ll find them useful.
Robert L. Glass
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 readingFacts 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!See all Product Description
Top Customer Reviews
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"
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.Read more ›
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.Read more ›
Most recent customer reviews
I recommend this book to any software person who wants to find out why most software projects that fail, fail. Read morePublished on July 10 2003 by S. Wuest
Once again, Glass has proven that he belongs in the software engineering pantheon along with Tom DeMarco, Gerry Weinberg, and Steve McConnell.
This book will open your eyes. Read more
Look for similar items by category
- Books > Computers & Technology > Computer Science > Software Engineering
- Books > Computers & Technology > Programming > Software Design, Testing & Engineering > Software Development
- Books > Computers & Technology > Project Management > PMP Exam
- Books > Computers & Technology > Software
- Books > Textbooks > Computer Science & Information Systems > Programming Languages
- Books > Textbooks > Computer Science & Information Systems > Software Design & Engineering