Facts and Fallacies of Software Engineering and over one million other books are available for Amazon Kindle. Learn more

Vous voulez voir cette page en français ? Cliquez ici.


or
Sign in to turn on 1-Click ordering.
or
Amazon Prime Free Trial required. Sign up when you check out. Learn More
More Buying Choices
Have one to sell? Sell yours here
Start reading Facts and Fallacies of Software Engineering on your Kindle in under a minute.

Don't have a Kindle? Get your Kindle here, or download a FREE Kindle Reading App.

Facts and Fallacies of Software Engineering [Paperback]

Robert L. Glass
5.0 out of 5 stars  See all reviews (6 customer reviews)
List Price: CDN$ 46.99
Price: CDN$ 29.60 & FREE Shipping. Details
You Save: CDN$ 17.39 (37%)
o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o
Only 2 left in stock (more on the way).
Ships from and sold by Amazon.ca. Gift-wrap available.
Want it delivered Tuesday, September 2? Choose One-Day Shipping at checkout.

Formats

Amazon Price New from Used from
Kindle Edition CDN $21.57  
Paperback CDN $29.60  
Save Up to 90% on Textbooks
Hit the books in Amazon.ca's Textbook Store and save up to 90% on used textbooks and 35% on new textbooks. Learn more.
Join Amazon Student in Canada


Book Description

Oct. 28 2002 0321117425 978-0321117427 1

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!


Special Offers and Product Promotions

  • Join Amazon Student in Canada


Frequently Bought Together

Facts and Fallacies of Software Engineering + The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition (2nd Edition) + Code Complete
Price For All Three: CDN$ 89.27


Customers Who Bought This Item Also Bought


Product Details


Product Description

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
Summer 2002



0321117425P09232002

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

Customer Reviews

4 star
0
3 star
0
2 star
0
1 star
0
5.0 out of 5 stars
5.0 out of 5 stars
Most helpful customer reviews
5.0 out of 5 stars On Computational Feasibility July 10 2003
Format:Paperback
I recommend this book to any software person who wants to find out why most software projects that fail, fail.
But my specific interest revolves around writing software in large engineering (hard engineering) companies, in that very peculiar environment. Specifically, the hard engineering environment in which knowledge of the programming language is considered the most advanced software theory needed to produce a product, and in which Electrical Engineers without any formal education in advanced data structures, algorithms to manipulate them, search strategies, and heuristics are writing most of the code.
I am seeing HUGE software projects fall FAR short of their schedulled goals, because those doing the coding have simply used up all their computational cycles (I'm talking about real-time software). In these situations, managers seem to imply
1. they were blindsided
2. there are no ways to forsee such computational box canyons
3. no one could have done better, anyway.
On all 3 points, managers are wrong. And the substance on which they are so badly wrong, would make for another 10 fallacies in Glass' book. For example:
Fallacy N: Hard engineers produce advanced software algorithms.
The average hard engineer is writing Freshman undergraduate code, and making basic errors in design.
Fallacy N+1: Simple code (meaning no Computer Science theory) is much more efficient than highly tailored software algorithms. Actually, it is often orders of magnitude less efficient.
Fallacy N+2: Analytical mathematical solutions are the only ones worthy of respect. Actually, with the incredibly complex problems in modern engineering, closed form mathematical solns may never be found.
Read more ›
Was this review helpful to you?
Format: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"
Was this review helpful to you?
Format: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.
Read more ›
Was this review helpful to you?
Want to see more reviews on this item?

Look for similar items by category


Feedback