Review:Software Runaways

Stern has written a review of Software Runaways -- Lessons Learned from Massive Software Project Failures. You know that delicious thrill you get from seeing massive destruction? Imagine that applied to software projects-click below for more information. Software Runaways -- Lessons Learned From Massive Software Project Failures author Robert L. Glass pages publisher Prentice-Hall, Inc. rating 9 reviewer Stern ISBN summary ulti-million dollar and multi-billion dollar software projects, the reasons they failed, the companies they destroyed, and the people to blame. The Scenario

Humans are drawn to scenes of carnage; we can't pass an accident on the highway without slowing to look for blood. Robert L. Glass reports on the car crashes of the computer industry -- massive software projects which failed, sometimes destroying the firms which created them.

Glass has been writing on these topics for decades, but this is his first book since 1987, and there have been a rich array of projects for him to discuss since then.

Much of the book is composed of articles written by other people, from the Wall Street Journal, Computer Decisions Magazine, and other periodicals and studies. These are uniformly well written, and Glass has selected a valuable set of outside sources.

What's Bad?

The books is not intended as a tutorial for programmers or even program managers. Those readers will find the book interesting, but I would suggest they turn to Steve McConnell's Software Project Survival Guide or similar books for how-to help. Software Runaways is intended for people operating at a political level, especially those confronted with management which believes that fundamental business problems can be solved by the deployment of new computer systems or trendy infrastructure designs.

What's Good?

Glass has no fear of assigning blame, naming the particular corporate executives, government officials or consulting companies whose incompetence or malfeasance led to disaster. He has a deep understanding of the superiority of software that works over software that is flashy or serves some conflicting interest of the decision maker or consultant. The book should be in the library of anybody who ever has to argue against the deployment of a new system.

The 1986 article "Anatomy of a 4GL Disaster", which describes the failed rollout of a new computer system at the New Jersey Division of Motor Vehicles is practically a political thriller. The 1996 article "When Things Go Wrong" describes how the failure of a $65 million inventory control system destroyed FoxMeyer Drug, a $5 billion company. Each reader will have a different favorite chapter, depending on the industries and technologies for which he has personally worked in the past.

So What's In It For Me?

Primarily, the book is fun to read. It is practically techno-porn. For those who work on massive software projects, this is also a collection of useful cautionary tales and lessons that may save you grief and money.

So, if you want to read up about all the pitfalls - and know how to avoid them, pick this book up over here.

Table of Contents

1. Introduction
2. Software Runaway War Stories
   1. Project Objectives Not Fully Specified
   2. Bad Planning and Estimating
   3. Technology New to the Organization
   4. Inadequate/No Project Management Methodology
   5. Insufficient Staff on the Team
   6. Poor Performance by Suppliers of Hardware/Software
   7. Other -- Performance (Efficiency) Problems
3. Software Runaway Remedies
4. Conclusions

Comments

When software goes bad.

[Anonymous Coward]

I can relate to bad software doing damage. I work in the manufacturing industry as a technician. Our production lines use coordinated DC motors up to 400 horsepower and various pneumatic and hydraulic devices to move things along. Traditionaly, we have used simple relays, or the more advanced PLC's. Things work great when its kept simple and they are easy to work with. If I get run over by a truck tomorrow, someone off the street can replace me to keep the plant running. Every machine operator's job should be secure.

Unfortunately, in the last few years, there has been a push to run things through computers with a operating system that is Not There yet. Worse yet is the programs that have not been tested to be fail safe. Debugging is a matter of blame. When the machines hicupp, the scrap piles up requiring forklifts to remove the heaps. A computer would be fine for monitoring a line and fine tuning operations, but for sole control of every instantaneous megawatt around operators and raw material is dangerous!

What I found most interesting was when the plant managers had their meeting with the suits, the director of the computing services was at the same table. When the subject about computer problems came up, I was told he sunk in his chair after the COO stated he was surprised that we had any computer problems.

We are trapped with a proprietary operating system with its proprietary programming systerm, and its proprietary office suite. I bet its all leased too. :(