Software Runaways : Monumental Software Disasters / Edition 1

Paperback (Print)
Used and New from Other Sellers
Used and New from Other Sellers
from $1.99
Usually ships in 1-2 business days
(Save 94%)
Other sellers (Paperback)
  • All (18) from $1.99   
  • New (4) from $24.00   
  • Used (14) from $1.99   

Overview

Failure often teaches more than success. This book shows what went wrong in 16 of the worst software disasters of recent years -- and shows how to prevent your own software disasters. Software failure expert Robert Glass reviews the major software disasters of the past decade, including both widely-publicized and less well-known fiascoes. He identifies six characteristics of impending failure, including elements rarely discussed in other software engineering texts, such as the overdependence on new technology and the failure to adequately consider performance issues. Among the failures Glass discusses are: the FAA's Air Traffic Control System; American Airlines' Confirm; and Bank of America's MasterNet. Most important, Glass presents specific lessons to be learned from each of these failures, so your software project won't show up on the nightly news. All software project managers, IS senior management, developers, and other software professionals.

Read More Show Less

Editorial Reviews

Booknews
Shows what went wrong in 16 colossal software disasters, identifies six characteristics of projects likely to fail, and tells how to avert disasters. Details software failures at organizations including the IRS, Westpac Bank, Denver Airport, and the Florida welfare system, and demonstrates strengths and weaknesses of typical responses to potential runaways, including risk management and issue management. For IT executives, project managers, and software developers. Annotation c. by Book News, Inc., Portland, Or.
Ray Tung

Software Runaways

One of the thoughts that sprang to my mind when I read Software Runaways by Robert Glass is that it is a good thing for the book, the author, and the publishing house that the world operates by Adam Smith's theories, where value is determined by supply and demand, instead of Karl Marx's, where value is determined by the work done. Perhaps that is a little too harsh, as Glass surely had to spend considerable time and energy compiling his articles, asking for permission to print, and lining up people to write their views on sundry topics. Nevertheless, it should be pointed out that a good portion of the book half? consists of articles culled from print media of widely ranging technicality from IEEE Software to Computerworld to the Wall Street Journal. On the other hand, most of the book, including Glass's own writing, was very readable and sometimes humorous.

At the beginning, Glass lists 6 major causes for failure along with a few pointers to potentially useful sources, such as a KPMG study published in Software World, vol. 26, no. 3 titled "Runaway Projects -- Causes and Effects". The six causes he lists are:

  1. Project Objectives Not Fully Specified
  2. Bad Planning and Estimation
  3. Technology New to the Organization
  4. Inadequate/No Project Management Methodology
  5. Insufficient Senior Staff on the Team
  6. Poor Performance by Suppliers of Hardware/Software

Certainly this list should inspire discussion. For instance, the case could be made that very few long projects could have their project objectives fully specified at the beginning since business requirements change fairly rapidly in most fields. Suffice it to say that the introduction was interesting enough to induce me to buy the book.

The great bulk of the book comes in the middle section, which consists of a collection of "war stories." The reason why I put the term in quotes is because the majority of the pieces were written by third party observers, not actual participants of the development efforts themselves. The pieces themselves were written with varying quality, of varying depth, and for different audiences.

As a broad overview of major software disasters, Software Runaways is quite complete, but I often found myself frustrated. Glass tended to be impartial, allowing more than one viewpoint in on the more acrimonious failures, and declining to offer judgment on most of the case studies though a few of the writers did so themselves. Perhaps a smaller collection of case studies researched more in depth would have been more profitable.

The book ends in a section titled "Software Runaway Remedies". Its format is very much like the introduction, in that pointers to other source material are offered along with some discussion of their conclusions. There are some thought-provoking and worthwhile observationsmade -- for example, the book prompted me to ask if my organization did postmortems on projects. The length of the final section, though, was shorter than expected. In summary, this book is a good read, and considering the paucity of useful material available in the trade press on software failures, may be a good buy.--Dr. Dobb's Electronic Review of Computer Books

Read More Show Less

Product Details

  • ISBN-13: 9780136734437
  • Publisher: Prentice Hall
  • Publication date: 9/18/1997
  • Edition description: New Edition
  • Edition number: 1
  • Pages: 259
  • Product dimensions: 5.98 (w) x 8.97 (h) x 0.63 (d)

Meet the Author

ROBERT L. GLASS is an author and consulting on software quality issues who has written more than 10 books on the topic. He owns his own company, Computing Trends, and writes a column on Software Engineering for ACM Communications Magazine.

Read More Show Less

Read an Excerpt

Preface

I've always been interested in computing projects that failed. There seems to be a much more indelible lesson to be learned from failures than from successes.

Some of you readers may know that I once wrote a column for a leading computing newspaper under an assumed name, and the content of the column was fictionalized failure stories. (I wrote it under an assumed name and fictionalized the stories, because I suspected that my employer at the time wouldn't appreciate my washing its dirty linen in public!) Those columns eventually became a book (The Universal Elixir and Other Computing Projects That Failed) and then grew to fill another (The Second Coming: More Computing Projects That Failed). They also became the basis for talks I frequently presented at chapters of my computing professional society, the ACM.

Buoyed by that success, I did it again (Computing Catastrophes, true stories of mainframe computing projects and companies that failed) and again (Computing Shakeout, true stories of microcomputer projects and companies that failed). I was on a roll. Failure was my fate!

But the last of those books was (self-) published in 1987, over a decade ago. It wasn't that I lost interest in failure; it was simply getting harder to find good failure stories! The frequency of early-day failures, and the shakeouts in the mainframe and microcomputer industries, had largely ended. Computing had become an almost boringly-successful field.

Some would, of course, take issue with that statement. Those who cry "software crisis" promote the belief that the software field is full of failure, with far too few successes in between. But that's not how I see it. In spite of the time I've spent finding and publishing failure stories, I believe that software is the dramatic success story of our age, the spark that ignites the Computing Era. There have been failures, of course; but what makes them interesting is partly that there aren't that many of them. It's what journalists and software people call "exception reporting"—we tend to focus on the things that go wrong, because they're more interesting or important than the run-of-the-mill things that go right. Well, I'm at it again! I've been gathering stories about software runaways for about 10 years now, and I have enough of them to put together yet another book. This book contains stories about the Denver Airport Baggage Handling System, the FAA Air Traffic Control System, the Internal Revenue Service Modernization effort, and a baker's dozen or so other examples of software projects that got way out of control, most of them crashing and burning (usually figuratively rather than literally!). Once a failure nut, always a failure nut!

One of the things I do as I accumulate stories for a book is to analyze the lessons they teach us. It's a good way to create an outline for the book, for one thing, and it's also a way to make sure that there's value added for the reader; these are not only fun stories to read, but the lessons make the reading a learning experience.

What I'd like to do in this preface is highlight for you some of the learning experiences from the material that follows. I think there are some particularly interesting things happening in our field, as reflected in these failures, and they don't always agree with what our textbooks and our research papers, and our newspapers and our televisions, are telling us.

First, let's get the predictable out of the way. Here are some things I discovered that match what our traditional sources of information tell us:

Most of the runaway projects are (or were) huge. It is well known in the field that huge projects are much more troublesome than smaller ones. These stories support that finding. Most runaway projects result from a multiplicity of causes. There may or may not be one dominant cause, but there are always several problems contributing to the runaway. Many of the runaway projects were lauded early in their history as being "breakthroughs," significant advances over the systems they were replacing. It appeared that visibility into the possibility of failure did not emerge until the project was well under way.

But the unpredictable is much more fascinating. Here are some characteristics of these runaway projects that none of my reading (and I suspect yours as well) prepared me for: Technology was just as often a cause of failure as management. The literature, especially in the software engineering field, tends to say that major failures are usually due to management. But for nearly half of these 16 failure stories the dominant problem was technical.

There were two especially surprising and dominant technical problems. The first was the use of new technology. Four of the projects, fully expecting to be breakthroughs because they were using the latest in software engineering concepts, instead failed because of them! One used a megapackage approach to replacing its old, legacy software, betting the company on the approach—and losing. Another used a Fourth Generation Language ("4GL," a problem-focused programming language) for a large project, and found (after the work was complete!) that it was not capable of meeting performance goals for the (on-line) system. Yet another tried to port an existing mainframe system to client/server, and found the complexity increase got out of hand. And the fourth put together so many new technologies that the project foundered from their sheer weight (that didn't prevent some of the project's principals from proclaiming the project a success in their company's house organ!).

The second dominant technical problem was performance. Many of these runaway projects were in some sense real-time (that in itself is a pertinent finding), and all too often the as-built systems simply were too slow to be useful. This is particularly interesting because most academic curricula now downplay the importance of system efficiency, with the thought that brute force hardware speed has done away with the need for more subtle software solutions. This data, at least, suggests that the field may have overplayed that hand.

In summary, I would like to say this: software runaways don't occur often in our field, but when they do they are increasingly visible. Many of the stories in my book were mentioned one or more times on TV and in general, print media news reports. And a surprising number of these projects, as evidenced both by the research findings I cite and by the stories I have collected, were flawed because of the technical (not just the management) approach. There are some words of warning here for those who embark on major software projects; none of us would like to see our best efforts become the headline story on the nightly news!

Robert L. Glass 1416 Sare Rd. Bloomington, IN 47401
Spring 1997 (two and a half years from what may become the Mother of All Software Failure Stories, the Year 2000 Date Crisis)

Read More Show Less

Table of Contents

1. Introduction.

What Is a Software Runaway? The Cries of Software Crisis. "Crunch Mode" and the "Death March" Project. Some Relevant Research Findings.

2. Software Runaway War Stories.

Project Objectives Not Fully Specified. Bad Planning and Estimating. Technology New to the Organization. Inadequate/No Project Management Methodology. Insufficient Senior Staff on the Team. Poor Performance by Suppliers of Hardware/Software. Other' Performance (Efficiency) Problems.

3. Software Runaway Remedies.

Risk Management. Issue Management. Remedies Attempted During Runaways. Remedies Envisioned for the Future.

4. Conclusions.

Index.

Read More Show Less

Preface

Preface

I've always been interested in computing projects that failed. There seems to be a much more indelible lesson to be learned from failures than from successes.

Some of you readers may know that I once wrote a column for a leading computing newspaper under an assumed name, and the content of the column was fictionalized failure stories. (I wrote it under an assumed name and fictionalized the stories, because I suspected that my employer at the time wouldn't appreciate my washing its dirty linen in public!) Those columns eventually became a book (The Universal Elixir and Other Computing Projects That Failed) and then grew to fill another (The Second Coming: More Computing Projects That Failed). They also became the basis for talks I frequently presented at chapters of my computing professional society, the ACM.

Buoyed by that success, I did it again (Computing Catastrophes, true stories of mainframe computing projects and companies that failed) and again (Computing Shakeout, true stories of microcomputer projects and companies that failed). I was on a roll. Failure was my fate!

But the last of those books was (self-) published in 1987, over a decade ago. It wasn't that I lost interest in failure; it was simply getting harder to find good failure stories! The frequency of early-day failures, and the shakeouts in the mainframe and microcomputer industries, had largely ended. Computing had become an almost boringly-successful field.

Some would, of course, take issue with that statement. Those who cry "software crisis" promote the belief that the software field is full of failure, with far too few successes in between. But that's not how I see it. In spite of the time I've spent finding and publishing failure stories, I believe that software is the dramatic success story of our age, the spark that ignites the Computing Era. There have been failures, of course; but what makes them interesting is partly that there aren't that many of them. It's what journalists and software people call "exception reporting"—we tend to focus on the things that go wrong, because they're more interesting or important than the run-of-the-mill things that go right. Well, I'm at it again! I've been gathering stories about software runaways for about 10 years now, and I have enough of them to put together yet another book. This book contains stories about the Denver Airport Baggage Handling System, the FAA Air Traffic Control System, the Internal Revenue Service Modernization effort, and a baker's dozen or so other examples of software projects that got way out of control, most of them crashing and burning (usually figuratively rather than literally!). Once a failure nut, always a failure nut!

One of the things I do as I accumulate stories for a book is to analyze the lessons they teach us. It's a good way to create an outline for the book, for one thing, and it's also a way to make sure that there's value added for the reader; these are not only fun stories to read, but the lessons make the reading a learning experience.

What I'd like to do in this preface is highlight for you some of the learning experiences from the material that follows. I think there are some particularly interesting things happening in our field, as reflected in these failures, and they don't always agree with what our textbooks and our research papers, and our newspapers and our televisions, are telling us.

First, let's get the predictable out of the way. Here are some things I discovered that match what our traditional sources of information tell us:

Most of the runaway projects are (or were) huge. It is well known in the field that huge projects are much more troublesome than smaller ones. These stories support that finding. Most runaway projects result from a multiplicity of causes. There may or may not be one dominant cause, but there are always several problems contributing to the runaway. Many of the runaway projects were lauded early in their history as being "breakthroughs," significant advances over the systems they were replacing. It appeared that visibility into the possibility of failure did not emerge until the project was well under way.

But the unpredictable is much more fascinating. Here are some characteristics of these runaway projects that none of my reading (and I suspect yours as well) prepared me for: Technology was just as often a cause of failure as management. The literature, especially in the software engineering field, tends to say that major failures are usually due to management. But for nearly half of these 16 failure stories the dominant problem was technical.

There were two especially surprising and dominant technical problems. The first was the use of new technology. Four of the projects, fully expecting to be breakthroughs because they were using the latest in software engineering concepts, instead failed because of them! One used a megapackage approach to replacing its old, legacy software, betting the company on the approach—and losing. Another used a Fourth Generation Language ("4GL," a problem-focused programming language) for a large project, and found (after the work was complete!) that it was not capable of meeting performance goals for the (on-line) system. Yet another tried to port an existing mainframe system to client/server, and found the complexity increase got out of hand. And the fourth put together so many new technologies that the project foundered from their sheer weight (that didn't prevent some of the project's principals from proclaiming the project a success in their company's house organ!).

The second dominant technical problem was performance. Many of these runaway projects were in some sense real-time (that in itself is a pertinent finding), and all too often the as-built systems simply were too slow to be useful. This is particularly interesting because most academic curricula now downplay the importance of system efficiency, with the thought that brute force hardware speed has done away with the need for more subtle software solutions. This data, at least, suggests that the field may have overplayed that hand.

In summary, I would like to say this: software runaways don't occur often in our field, but when they do they are increasingly visible. Many of the stories in my book were mentioned one or more times on TV and in general, print media news reports. And a surprising number of these projects, as evidenced both by the research findings I cite and by the stories I have collected, were flawed because of the technical (not just the management) approach. There are some words of warning here for those who embark on major software projects; none of us would like to see our best efforts become the headline story on the nightly news!

Robert L. Glass 1416 Sare Rd. Bloomington, IN 47401
Spring 1997 (two and a half years from what may become the Mother of All Software Failure Stories, the Year 2000 Date Crisis)

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)