Software Runaways: Monumental Software Disasters by Robert L. Glass

• Table of Contents
• Forewords & Introductions
• Read an Excerpt

Table of Contents

Forewords & Introductions

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 fartoofew 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 an Excerpt

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 toofew 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)