Slashdot Log In
Review:Software Runaways
from the when-things-go-wrong dept.
| 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
- Introduction
- Software Runaway War Stories
- Project Objectives Not Fully Specified
- Bad Planning and Estimating
- Technology New to the Organization
- Inadequate/No Project Management Methodology
- Insufficient Staff on the Team
- Poor Performance by Suppliers of Hardware/Software
- Other -- Performance (Efficiency) Problems
- Software Runaway Remedies
- Conclusions
Many Large Projects Fails (Score:4)
When I worked as a consultant a client had some questions about the quality of the work that was performed. I did some research into software quality and discovered that despite the problems my project had, we had actually performed far above average. (The system was successful has been in production for some time). Two of the keys to our success were good scope control and aggressive defect containment program.
Scope control is an obvious success factor, but finding and correcting defects as close to the time of occurrence is absolutely critical as well. (We tried to "contain" our defects within the project stage where they originated via a long list of formal exit criteria for a given development stage). It's obvious, but worth repeating, errors in requirements are many, many, many times more costly to correct than simple programming errors. Of course you'd still better "plan to throw one away". But the key is to make sure you do a good enough job at requirements definition and system design that one is it!
When software goes bad. (Score:5)
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.