BN.com Gift Guide

Computing Calamities: Monumental Computing Disasters

Overview

Many great advances in technology have resulted from risky experimentation, but it's critical to remember and study the spectacular failures that also resulted from some of those risks. Failures can be mundane, like the typical complaints of software projects that are behind schedule and over budget, while others can be much more extravagant. In Computing Calamities, Robert L. Glass has collected war stories from around the industry. Laugh at these mistakes, and learn from them. Someone else's failure could be ...
See more details below
Available through our Marketplace sellers.
Other sellers (Paperback)
  • All (11) from $3.24   
  • New (1) from $195.00   
  • Used (10) from $3.24   
Close
Sort by
Page 1 of 1
Showing All
Note: Marketplace items are not eligible for any BN.com coupons and promotions
$195.00
Seller since 2014

Feedback rating:

(193)

Condition:

New — never opened or used in original packaging.

Like New — packaging may have been opened. A "Like New" item is suitable to give as a gift.

Very Good — may have minor signs of wear on packaging but item works perfectly and has no damage.

Good — item is in good condition but packaging may have signs of shelf wear/aging or torn packaging. All specific defects should be noted in the Comments section associated with each item.

Acceptable — item is in working order but may show signs of wear such as scratches or torn packaging. All specific defects should be noted in the Comments section associated with each item.

Used — An item that has been opened and may show signs of wear. All specific defects should be noted in the Comments section associated with each item.

Refurbished — A used item that has been renewed or updated and verified to be in proper working condition. Not necessarily completed by the original manufacturer.

New
Brand new.

Ships from: acton, MA

Usually ships in 1-2 business days

  • Standard, 48 States
  • Standard (AK, HI)
Page 1 of 1
Showing All
Close
Sort by
Sending request ...

Overview

Many great advances in technology have resulted from risky experimentation, but it's critical to remember and study the spectacular failures that also resulted from some of those risks. Failures can be mundane, like the typical complaints of software projects that are behind schedule and over budget, while others can be much more extravagant. In Computing Calamities, Robert L. Glass has collected war stories from around the industry. Laugh at these mistakes, and learn from them. Someone else's failure could be the foundation of your success.
Read More Show Less

Editorial Reviews

Booknews
Collects stories of software failures and other failures related to computers in the business world from newspapers, computing periodicals, and other sources. Meant to instruct managers in strategies to avoid, the stories come from such companies as Atari, Wang, Seiko, AT&T, and Citicorp. Annotation c. by Book News, Inc., Portland, Or.
Read More Show Less

Product Details

  • ISBN-13: 9780130828620
  • Publisher: Prentice Hall Professional Technical Reference
  • Publication date: 11/12/1998
  • Edition number: 1
  • Pages: 352

Read an Excerpt

PREFACE: Introduction: What's So Great About Failure?
Do computing companies and projects fail more often than other companies and projects? Sometimes it feels like it. There, on the nightly news, is yet another tale of woe, a story related to computing that shows some stupid computing system doing something that no sensible human being would ever have done. There, in the computing literature, are the findings of yet another survey saying that 57%, or 68%, or 95% of computing projects fail. There, on the Nightly Business Report, is the story of a computing company whose stock just did a nose-dive into obscurity.

But there is something, I want to say, badly wrong with that picture. For every stupid computer trick on the nightly news, there are a hundred interactions that all of us have with a variety of computing systems on a daily basis where nothing whatsoever goes wrong. For every survey finding showing that an enormous number of computing projects fail, there are systems up and running and doing precisely what they are supposed to do, in companies ranging from the Fortune 500 to the not-so-Fortunate 5,000,000. For every stock nose-dive on NBR, there are stratospheric rises of some other computing company's stock. Something is wrong with that picture, indeed!

To be honest, I don't quite understand what's going on. I read those surveys by quite reputable companies that say things like "84% of US IT projects fail to meet original expectations and 94% of those started have to be restarted" (the Standish Group, published in 1997), and 85% of UK companies "reported problems with systems projects that were either late, over budget, or that fail todeliver planned benefits" (Coopers & Lybrand's Computer Assurance Services risk management group, also published in 1997). And I see lots of other data points that come out telling a roughly similar story.

But the more of those stories I read, the more perplexed I get. For one thing, although lots of these stories quote high percentages of computing project failure, there's very little consistency in the numbers. For example, Standish, which gave us the 84% and 94% figures I quoted above, gave us another set of data in 1995 and 1996; they said (for 1995) that 31% of projects failed and 53% were "challenged," and (for 1996) 40% failed and 33% were "challenged." Other figures from other sources tell a similarly inconsistent story. I could find you data saying that the correct percentage of failed computer projects is 46%, or 62%, or 81%, or any number you'd care to name. And the dilemma here is, those figures simply can't all be right!

I'm a professional in the computing field. I've participated in a lot of projects over the years. Some of them failed. A lot more of them didn't. I very strongly believe that those failure numbers, the ones I've been quoting to you above, are very sincerely obtained-and very wrong!

Some of my best friends in college (ah, those days have long been gone!) were ministerial students. When they wanted to say something nice about the trial sermon that one of them had just given but there was little to compliment, they would say "Well, you were sincere!" That's the sense in which I use the word "sincere" to describe my computing colleagues who generate or quote those failure statistics! I don't think any of them are being insincere; I just think their numbers are relatively worthless.

Let me tell you a story about computing failure stories. Several years ago, it was popular for people who studied the field of computing to speak of a "software crisis." When they named that crisis, what they really meant was that software had the reputation of being "always behind schedule, over budget, and unreliable." To support their declaration of a crisis, they would often quote numbers from a study by a US Government watchdog agency, the Government Accounting Office (GAO), which showed that a very high percentage of government software projects they tracked had failed.

The use of these GAO numbers persisted for several years. Then a colleague of mine got curious about the GAO report, and read the original study. He discovered, much to his surprise (and what should have been the chagrin of many computing professionals), that the study was being misinterpreted. The GAO had found a high percentage of failed projects, but the projects it had tracked were already in trouble when the GAO began studying them! In other words, the simple and clear message of the GAO study was that a large percentage of software projects that got into trouble never rose above that trouble. And anyone who used that study to try to show anything else-for example, that a large percentage of all software projects failed-had misunderstood the data.

Call me crazy, but I think a lot of that computing project failure data, when the smoke all clears away, will be of this kind. Misused numbers. Failures to use agreed-upon definitions of terms. Gathering information from biased sources. Making up numbers to fit a preconceived notion.

So, given all of that, what the heck am I doing writing a book about computing calamities? Doesn't a book telling computing failure stories tend to reinforce the notion that computing failure is common? Shouldn't I be trying to write a book about computing successes, instead, to prove the point I apparently so deeply believe in?

There are several reasons why I have chosen to write this book on failure:
  1. Failure is a far stronger learning experience than success. I hope that these stories of failure will contain some lessons learned of value to you.
  2. Failure is just plain fun! I have no idea why we human beings laugh at pies in the face and pratfalls down a flight of stairs, but it seems-for better or worse-to be part of our humanity. I think you're going to enjoy reading the things I've written.
  3. Success is transient. I once added a success story to an earlier book I wrote about failure. It told the story of the Intel 286 chip, and what a great design it was. Ten years or so have now passed since I put that book together. Every single one of the other stories in that book is still up-to-date-none of the failed projects I wrote about ever came back to life! But the 286 is ancient history. And that story dates the book like nothing else I said in it.
  4. I'm a failure nut! This isn't, as I hinted above, the first book I've written about computing failure. I once wrote a column for Computerworld, way back in the 1960s, which consisted largely of computing failure stories. (The column used disguised names for the people and places whose stories I told, and I wrote it under an assumed name, Miles Benson!) I collected those columns into a couple of self-published books in the 1970s. I also gathered stories about early computing companies and projects that failed, both during the mainframe era and the early microcomputer era, and published those books during the 1980s. And, in fact, I wrote a predecessor to this book, Software Runaways, which Prentice-Hall published in 1998 (actually, the fall of 1997-like car companies, publishers label books that come out in the fall with the model year still to come!), and which has sold quite handsomely (perhaps that's why you're reading this one!)

The question that began this chapter of the book was "What's so great about failure?" I think I've given you at least an implicit answer to that question. Failure is a learning experience. Failure is fun. Success is transient, and failure usually isn't. Failure never quits happening.

Many of the failure stories I have published over the years were written by someone else. I take a hunter-gatherer approach to these stories, reading quite a bit of the computing literature and a slice of the more general literature, looking for in-depth reports by careful journalists who have pursued a computing failure story and come up with a well-told, fact-based, human-interest-focused tale. Nearly all of the stories in this book are from sources other than me, from publications ranging from Computerworld to the Wall Street Journal. (The source of each story is found at the beginning of the story.)

I love gathering and telling these failure stories. Not because they prove a point-as you have already seen, I don't believe they do-but because I personally find them fascinating and fun.

I hope you do, too!

Robert L. Glass
Summer, 1998
Read More Show Less

Table of Contents

Foreword
About the Author
1 Introduction: What's So Great About Failure? 1
2 Overview: The Many Faces of Failure 7
3 Keep Your Eyes on the Enterprise: Stories of Corporate Failure 33
4 Mission Impossible's Dirty Little Secrets: Stories of Project and Product Failure 189
5 The Taming of the Shrewd: Stories of Failures of the Best and Brightest 265
6 Summary: Now Remind Me - What's So Great About Failure? 291
Index 295
Read More Show Less

Preface

Introduction: What's So Great About Failure?
Do computing companies and projects fail more often than other companies and projects? Sometimes it feels like it. There, on the nightly news, is yet another tale of woe, a story related to computing that shows some stupid computing system doing something that no sensible human being would ever have done. There, in the computing literature, are the findings of yet another survey saying that 57%, or 68%, or 95% of computing projects fail. There, on the Nightly Business Report, is the story of a computing company whose stock just did a nose-dive into obscurity.

But there is something, I want to say, badly wrong with that picture. For every stupid computer trick on the nightly news, there are a hundred interactions that all of us have with a variety of computing systems on a daily basis where nothing whatsoever goes wrong. For every survey finding showing that an enormous number of computing projects fail, there are systems up and running and doing precisely what they are supposed to do, in companies ranging from the Fortune 500 to the not-so-Fortunate 5,000,000. For every stock nose-dive on NBR, there are stratospheric rises of some other computing company's stock. Something is wrong with that picture, indeed!

To be honest, I don't quite understand what's going on. I read those surveys by quite reputable companies that say things like "84% of US IT projects fail to meet original expectations and 94% of those started have to be restarted" (the Standish Group, published in 1997), and 85% of UK companies "reported problems with systems projects that were either late, over budget, or that fail to deliverplanned benefits" (Coopers & Lybrand's Computer Assurance Services risk management group, also published in 1997). And I see lots of other data points that come out telling a roughly similar story.

But the more of those stories I read, the more perplexed I get. For one thing, although lots of these stories quote high percentages of computing project failure, there's very little consistency in the numbers. For example, Standish, which gave us the 84% and 94% figures I quoted above, gave us another set of data in 1995 and 1996; they said (for 1995) that 31% of projects failed and 53% were "challenged," and (for 1996) 40% failed and 33% were "challenged." Other figures from other sources tell a similarly inconsistent story. I could find you data saying that the correct percentage of failed computer projects is 46%, or 62%, or 81%, or any number you'd care to name. And the dilemma here is, those figures simply can't all be right!

I'm a professional in the computing field. I've participated in a lot of projects over the years. Some of them failed. A lot more of them didn't. I very strongly believe that those failure numbers, the ones I've been quoting to you above, are very sincerely obtained-and very wrong!

Some of my best friends in college (ah, those days have long been gone!) were ministerial students. When they wanted to say something nice about the trial sermon that one of them had just given but there was little to compliment, they would say "Well, you were sincere!" That's the sense in which I use the word "sincere" to describe my computing colleagues who generate or quote those failure statistics! I don't think any of them are being insincere; I just think their numbers are relatively worthless.

Let me tell you a story about computing failure stories. Several years ago, it was popular for people who studied the field of computing to speak of a "software crisis." When they named that crisis, what they really meant was that software had the reputation of being "always behind schedule, over budget, and unreliable." To support their declaration of a crisis, they would often quote numbers from a study by a US Government watchdog agency, the Government Accounting Office (GAO), which showed that a very high percentage of government software projects they tracked had failed.

The use of these GAO numbers persisted for several years. Then a colleague of mine got curious about the GAO report, and read the original study. He discovered, much to his surprise (and what should have been the chagrin of many computing professionals), that the study was being misinterpreted. The GAO had found a high percentage of failed projects, but the projects it had tracked were already in trouble when the GAO began studying them! In other words, the simple and clear message of the GAO study was that a large percentage of software projects that got into trouble never rose above that trouble. And anyone who used that study to try to show anything else-for example, that a large percentage of all software projects failed-had misunderstood the data.

Call me crazy, but I think a lot of that computing project failure data, when the smoke all clears away, will be of this kind. Misused numbers. Failures to use agreed-upon definitions of terms. Gathering information from biased sources. Making up numbers to fit a preconceived notion.

So, given all of that, what the heck am I doing writing a book about computing calamities? Doesn't a book telling computing failure stories tend to reinforce the notion that computing failure is common? Shouldn't I be trying to write a book about computing successes, instead, to prove the point I apparently so deeply believe in?

There are several reasons why I have chosen to write this book on failure:
  1. Failure is a far stronger learning experience than success. I hope that these stories of failure will contain some lessons learned of value to you.
  2. Failure is just plain fun! I have no idea why we human beings laugh at pies in the face and pratfalls down a flight of stairs, but it seems-for better or worse-to be part of our humanity. I think you're going to enjoy reading the things I've written.
  3. Success is transient. I once added a success story to an earlier book I wrote about failure. It told the story of the Intel 286 chip, and what a great design it was. Ten years or so have now passed since I put that book together. Every single one of the other stories in that book is still up-to-date-none of the failed projects I wrote about ever came back to life! But the 286 is ancient history. And that story dates the book like nothing else I said in it.
  4. I'm a failure nut! This isn't, as I hinted above, the first book I've written about computing failure. I once wrote a column for Computerworld, way back in the 1960s, which consisted largely of computing failure stories. (The column used disguised names for the people and places whose stories I told, and I wrote it under an assumed name, Miles Benson!) I collected those columns into a couple of self-published books in the 1970s. I also gathered stories about early computing companies and projects that failed, both during the mainframe era and the early microcomputer era, and published those books during the 1980s. And, in fact, I wrote a predecessor to this book, Software Runaways, which Prentice-Hall published in 1998 (actually, the fall of 1997-like car companies, publishers label books that come out in the fall with the model year still to come!), and which has sold quite handsomely (perhaps that's why you're reading this one!)

The question that began this chapter of the book was "What's so great about failure?" I think I've given you at least an implicit answer to that question. Failure is a learning experience. Failure is fun. Success is transient, and failure usually isn't. Failure never quits happening.

Many of the failure stories I have published over the years were written by someone else. I take a hunter-gatherer approach to these stories, reading quite a bit of the computing literature and a slice of the more general literature, looking for in-depth reports by careful journalists who have pursued a computing failure story and come up with a well-told, fact-based, human-interest-focused tale. Nearly all of the stories in this book are from sources other than me, from publications ranging from Computerworld to the Wall Street Journal. (The source of each story is found at the beginning of the story.)

I love gathering and telling these failure stories. Not because they prove a point-as you have already seen, I don't believe they do-but because I personally find them fascinating and fun.

I hope you do, too!

Robert L. Glass
Summer, 1998
Read More Show Less

Customer Reviews

Be the first to write a review
( 0 )
Rating Distribution

5 Star

(0)

4 Star

(0)

3 Star

(0)

2 Star

(0)

1 Star

(0)

Your Rating:

Your Name: Create a Pen Name or

Barnes & Noble.com Review Rules

Our reader reviews allow you to share your comments on titles you liked, or didn't, with others. By submitting an online review, you are representing to Barnes & Noble.com that all information contained in your review is original and accurate in all respects, and that the submission of such content by you and the posting of such content by Barnes & Noble.com does not and will not violate the rights of any third party. Please follow the rules below to help ensure that your review can be posted.

Reviews by Our Customers Under the Age of 13

We highly value and respect everyone's opinion concerning the titles we offer. However, we cannot allow persons under the age of 13 to have accounts at BN.com or to post customer reviews. Please see our Terms of Use for more details.

What to exclude from your review:

Please do not write about reviews, commentary, or information posted on the product page. If you see any errors in the information on the product page, please send us an email.

Reviews should not contain any of the following:

  • - HTML tags, profanity, obscenities, vulgarities, or comments that defame anyone
  • - Time-sensitive information such as tour dates, signings, lectures, etc.
  • - Single-word reviews. Other people will read your review to discover why you liked or didn't like the title. Be descriptive.
  • - Comments focusing on the author or that may ruin the ending for others
  • - Phone numbers, addresses, URLs
  • - Pricing and availability information or alternative ordering information
  • - Advertisements or commercial solicitation

Reminder:

  • - By submitting a review, you grant to Barnes & Noble.com and its sublicensees the royalty-free, perpetual, irrevocable right and license to use the review in accordance with the Barnes & Noble.com Terms of Use.
  • - Barnes & Noble.com reserves the right not to post any review -- particularly those that do not follow the terms and conditions of these Rules. Barnes & Noble.com also reserves the right to remove any review at any time without notice.
  • - See Terms of Use for other conditions and disclaimers.
Search for Products You'd Like to Recommend

Recommend other products that relate to your review. Just search for them below and share!

Create a Pen Name

Your Pen Name is your unique identity on BN.com. It will appear on the reviews you write and other website activities. Your Pen Name cannot be edited, changed or deleted once submitted.

 
Your Pen Name can be any combination of alphanumeric characters (plus - and _), and must be at least two characters long.

Continue Anonymously

    If you find inappropriate content, please report it to Barnes & Noble
    Why is this product inappropriate?
    Comments (optional)