From Book News, Inc.
With this book those who build and research software can rediscover fundamental facts, and a few fallacies, about management, the software development life cycle, quality, and software research. For each fact, there is a general discussion, then material on related controversies, and a list of recent and "ancient" (1970s and 1980s) sources of information. Glass has written many books on software engineering.Copyright © 2004 Book News, Inc., Portland, OR


Book Info
This guide identifies many of the key problems hampering success in this field. Covers management, all stages of the software lifecycle, quality, research, and more. Author presents ten common fallacies that help support the fifty-five facts. Softcover.


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!

0321117425B09232002


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.

0321117425AB09232002


Excerpt. © Reprinted by permission. All rights reserved.

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 managementAbout the life cycleAbout qualityAbout research

The fallacies are aggregated similarly:
About managementAbout the life cycleAbout 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
Summer 2002

0321117425P09232002

FROM THE PUBLISHER

The practice of building software is a “new kid on the block” technology. To those who have been in this field for all of their professional careers, it may not seem that way. But 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. In reading Facts and Fallacies of Software Engineering, the reader will 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 in the book is accompanied by a discussion of whatever controversy envelops it. You may find yourself agreeing with a lot of the facts and fallacies, and 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—practitioner or theoretician, you forget or neglect them at your peril.

SYNOPSIS

With this book those who build and research software can rediscover fundamental facts, and a few fallacies, about management, the software development life cycle, quality, and software research. For each fact, there is a general discussion, then material on related controversies, and a list of recent and "ancient" (1970s and 1980s) sources of information. Glass has written many books on software engineering. Annotation c. Book News, Inc., Portland, OR

ACCREDITATION