Crash: Learning from the World's Worst Computer Disasters [Paperback]

Essential reading.

While the authors break the chapters up, seemingly, according to topic they never seem to actually focus on the intended topic (and in a few cases, spread the "topic" over three or more chapters e.g. the "Lawyers" chapters). In my experience this resulted in a lack of closure on the completion of each chapter (i.e. I found it difficult to answer the question "what have I learned here"). The authors also tend to diverge quite a bit from the points they try to make by going into seemingly extensive discussions regarding the projects reviewed without actually adding any detail (the realtively short bibliography at the back of the book is further testament to this). This is most evident in one of the last chapters which covers 5 steps to follow in order to avoid the common pitfalls - I'm still not sure what the five steps are. In fact, if it wasn't for the fact that the points they were trying to make were in bold, I might have missed them all together.

Being a technical person I also found the format too literary and lacking in detail (i.e. what hardware was used, what software was used - something which the authors themselves acknowledge as being important). I suspect that this may have something to do with the fact that the authors are trade journalists and do not necessarily have first hand experience of what goes into a software development project. I believe this conclusion is further supported by the authors obvious bias towards "business" (as opposed to "the supplier").

Most of the projects focused on were also of the "massive" variety (i.e. costing in the tens of millions of pounds and taking years to complete) which, I believe, made the analysis afforded them, a bit simplistic (in fairness they were mostly public sector projects which were probably easier to source documentation on).

From what I have said you might think that this book is not worth reading but this is not the case. It does indeed offer valuable insights into the industry if you are prepared to sift through a lot of fluff and pompous words (the first or second chapter is called "Pusillanimity"). I think the book could however be packaged into a more easily consumable format through the shedding of 200 pages and the distilling of its essence into standardised reviews/post mortems with a bulleted list of things to learn/avoid/watch out for.

The main messages appear to be: do it in stages, make sure end-users have a say but in a controlled way, prototyping is a good way to introduce new concepts, the developers should really understand the business before beginning and the business shoud be re-organised BEFORE IT is concidered.

All the above form the basis of a development methodology called DSDM (Dynamic Systems Development Method) that is gaining in acceptance throughout Britain and Europe. Maybe there is a hope for the future.