Slashdot Mirror
Review:Software Runaways
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
What scares me most are all of the SCADA folks who come dancing in with their puppet show and try to claim they can do Real-Time control with what amounts to a VB application with some silly little DDE server, and all for $50,000 dollars a site. One of them recently sold one of our management types on how they could not only do SCADA and Process Control on a Not There box, but the same system would happily do all of our Office System automation and DP stuff with OLAP as well!
When I gave them a description of the systems they were proposing they replace and listed the 6 operating systems (including QNX and OS9) that they were claiming they could outperform and outlast on uptime, I asked them to send me a detailed proposal listing which component of their system would handle each task and just a guestimated MTBF.
I never heard from them again, but they keep taking their Management Boy out to lunch.
The other day, Management Boy told me the reason the engineers don't like Not There OS is because we, "Don't understand it."
I explained that I spent 8 years in M$HELL and asked him if he knew that device drivers all share the same priority level in Not There OS. Or if he could give me a definition of Real Time?
I probably shouldn't speak that way to a guy who's probably about number two in the company, but I was about ready to ring his neck!
So I stopped work on the 100% java OLAP app I've been working on for a year and started an OSS implementation of the BASIC09 syntax for Linux to work with an A/B PLC for some of our softer control stuff. I figure while they run around in circles, I'll get something coded that does the job and tell them about it after we've installed a few.
RMS take me away!
-monk
[-- Trust the Monkey --]
When you see this in your manager's code:
if (TRUE) then
DoSomething()
endif
if (FALSE) then
DoSomethingElse()
endif
if (!TRUE) and (!FALSE) then
WhyDoesntThisWorkMustBeACompilerError()
endif
Let's be fair about this - although I totally agree that we're almost all pro-Linux/OpenSource advocates here, it's stupid to say that someone who's ideas differ should leave. So he likes Microsoft and isn't a big fan of Netscape... Big deal. That doesn't mean he's a henchman working under the wing of Bill Gates.
If two people agree on everything all the time, then one of them isn't necessary.
The stats are large software project failures is amazing. I seem to recall from Capers Jones' Applied Software Measurement (an excellent book BTW) that 40% of "large" projects fail. (I can't remember, but I think that a large project is one with more than 1000 function points. I don't have the book with me). That is, they are never actually put into production for even one day.
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!
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.