After the Gold Rush book review

Authors: Steve McConnell ISBN: 0735608776 Publisher: Microsoft Press

One of the things that I used to find puzzling was how Microsoft Press released some of the best books on software engineering and application development while maintaining the level of quality they are famous for. I eventually realised that it was simple, all of the best programmers were writing books instead of code. When your sitting in front of a screen looking at another bluescreen cyou may argue with this being a good thing but if you’ve ever read any of McConnell’s other books such as Code Complete you’ll find the trade off to be acceptable. After the Gold Rush is a book not so much about how to engineer software as to where the author sees the profession heading and his views on how we should get there. The book itself is a brief read coming in at a mere 156 page of actual text and for people who have read Code Complete the lack of hard technical details may be off putting. If on the other hand you are planning to make a career out of developing software then it raises some important points that bear consideration. The basic premise of the book is that software development is currently stagnating in the realm of being a craft where a number of people have reached and stumbled in to a tar pit. Effort is wasted pulling all night coding runs in ‘code and fix type projects’ instead of being used for sensible planning that allows a lot of the reworking to be avoided. To a large extent I agree with the author (I may be biased coming from an engineering background…) in that software engineering needs to become more of an engineering discipline and less of an art form where reliability and failed deadlines run riot[0]. The book is broken up in to three sections, 1 The Tar Pit 2 Prospecting 3 Through The Pillars The first section of the book gives good coverage of where we currently are and has weathered the three years since the books release quite well. In-depth explanations and market gathered figures show how the average project hits trouble due to the JFDI[1] attitude and then has to go to ridiculous lengths to try and right itself. Chapter 3 is notable as it delves a little way in to the personality of a developer and makes both entertaining reading and illustrates the point that 30 year-old coders with a family are less inclined to work double hours without a pretty good reason. The second section of the book is the one I enjoyed the least. It’s a gathering ground of proof on why where we are now is a bad place and covers some of the suggestions on why the average project techniques and the best ones are such a world apart and how we can bridge the gap moving forward. The third part of the book will either strike a chord with you or leave you in complete disagreement with the author. The author’s views on why he believes software engineering as a profession needs to have certification applied to it are presented to the reader. This is a topic that most people have a view on and while this book gives some good reasons why it may be needed I doubt it alone will sway many of the people against certification. This is followed by the current plans of different States (The author uses North America and Canada for most of his examples) in regards to the licensing of software engineers. The emerging plans for software engineers to be treated in similar ways to other professionals such as Attorneys and Nurses is intriguing reading and also lightly touches upon the point of software liability but does not explore it in any depth, especially from a Free Software point of view. A short diversion in to the influence and increasing irrelevance of higher education in the world of high tech jobs rounds out the third section. Some valid points are raised about the diffusion of good practises and how one of the most successful practitioners (The US Agricultural Extension Service) has managed to make so many large-scale changes quickly and what we can learn from them. In general I liked the book and it made me think about where software engineering as a profession could head in the future and my views on whether I’d still like to be involved. A short, cheap read on where one of the luminaries of the trade sees us heading. 6/10 [0] I don’t expect everyone to agree with that point. [1] Just Friggin Do It