Crash : Ten Easy Ways to Avoid a Computer Disaster

Rating:
Summary: Could benefit from a reduced page count and more stucture
Review: I must admit that being in "the industry" is the main reason why I bought this book. I was also pleased to see that someone had finally put down on paper some of the issues which seem to plague the IT business. That said however it did take me two attempts to successfully complete the journey from cover to cover. There are numerous reasons for this.

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

Rating:
Summary: Could benefit from a reduced page count and more stucture
Review: I must admit that being in "the industry" is the main reason why I bought this book. I was also pleased to see that someone had finally put down on paper some of the issues which seem to plague the IT business. That said however it did take me two attempts to successfully complete the journey from cover to cover. There are numerous reasons for this.

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

Rating:
Summary: Avoiding the Crash
Review: In this book, Tony Collins spells out the finer points of project failures. He deals with the nitty gritty of some of the most expensive computer blunders made, both in the public and private sectors, in language that is easily understood and not full of techno jargon. This book is a must for anyone, customer or developer, thinking on embarking on a computer project. Tony lists what he calls the 10 deadly sins, and explains how each sin has contributed to a particular disaster. He reveals inside information on projects like the Wessex Health Authority catastrophe which cost the taxpayer over £60m, and how the government went on to reward those responsible. Like Fred Brooks' Mythical Man Month, this book should be compulsory reading in every college and university that teaches any computer related subjects. As a third year Compute Science student at Durham University, it certainly opened my eyes.