The Independent Magazine
for Software Developers
Books Articles Blogs Subscribe d.* Gear About Home
Book Review

After the Gold Rush Book Cover Image - Link to Purchase Book

After the Gold Rush

By Steve McConnell (Review by Andy Tegethoff)
Microsoft Press, 1999, 182 pages (ISBN 0735608776)
Published September 2, 2003

Since Code Complete maintains its perennial position on my computer bookshelf, I was curious as to whether Steve McConnell’s After the Gold Rush would make a similarly strong impression.Code Complete is a book that I have referred to again and again for its wisdom about the most basic aspects of quality coding. Naming conventions, cohesion and coupling, layout, commenting, control structures—the book is loaded with discussions of elements both aesthetic and functional which any developer worth his mouse should be aware of. I’ve recommended it to colleagues and loaned out my copy to many junior developers. I think it’s one that everyone in the profession could benefit from reading.

Admittedly, After the Gold Rush is not the same type of book. But it does have similarly powerful advice to dispense. There is plenty of wisdom distributed throughout this book of essays, enough to cause any seasoned software professional to consider the general state of the software development profession. McConnell’s writing style and solid arguments make for enjoyable reading, as well.

McConnell puts the industry at large through the debugger and finds that overuse of acknowledged worst practices (i.e. "code-and-fix development", individuals tackling Herculean programming feats, "Gold Rush" attempts to hurry a product along for market advantage) are largely at fault for the majority of failed projects and bad software churned out yearly. He reasons that, given the accelerated integration of technology into society and the consequent need for effective and reliable software, programming must mature and mold itself into a much more organized and cohesive profession.

McConnell posits Engineering as the ideal model for that professional maturation process, and he makes many solid arguments in its favor. Most of these points are based on the central idea of reusability. This is not just recycling the data access library you wrote for your last project, or getting the most out of that expensive GUI charting widget. McConnell instead refers to reusability in the more general sense of utilizing predictable best practices that can be relied on to produce successful results. Design patterns, configuration management tools and techniques, requirements gathering processes, code reviews, and test cases are all part of the reusable knowledge base available to the software industry. McConnell argues, sometimes seemingly in disbelief, that the majority of the industry is simply not using these well-known and well-defined practices.

His solutions for these ills involve better and more standardized education and a more stringent certification or licensing program for coders entering the profession. He feels that, as in engineering or any number of other professional vocations, software developers should meet certain minimum educational and experiential standards to be fully accredited. Other elements of governance missing from the software domain that exist within other professions, such as quasi-mandatory professional societies (like the American Bar Association for lawyers) and codes of ethics (like the medical profession’s Hippocratic Oath), provide a foundation on which to base a self-imposed set of operating standards.

The reasoning here is very sound at the societal level, if not from the perspective of every single developer currently working. Ask yourself: why is it that programmers, who build technology used in trust by potentially millions of people everyday, should be subject to less licensing and certification than a hairdresser? For me, this point is the crux of the book and the real seed of thought to gain from it. Software is too critical in almost every area of our lives, from balancing checkbooks to maintaining coolant levels in cars to controlling air traffic, to not require some degree of baseline mandated level of expertise.

But here also, in my opinion, is the book’s major weakness. Is engineering really the best model across the board, for all programming efforts? Does every single project require zero fault tolerance and the expense and time that come with attaining that goal? A very solid argument could be made by business software developers against the universal application of certain "best practices," an argument that takes into account the realities of the actual software profession.

For example, in development contexts where requirements and schedules change on a dime, the penalty of an extensive documentation effort outweighs the benefit. To my thinking, the sorts of environments where agility and adaptability are key lend themselves logically to a "craftsmanship" model. There is an academic-style removal from reality in some of McConnell’s analysis—not a lack of realism, but a dismissal of certain business facts that intrude on the desired orderliness of methodical software engineering. Further, many of those "reality vs. ideality" issues may not ring true for entire subsets of the development profession, especially those who program in the more scientific arenas where high-levels of process standardization already exist.

To be sure, some programming is, in fact, rocket science–especially if one happens to work for NASA. Projects in that vein—like modeling the behavior of rockets, or tracking jumbo jets, or precisely welding steel support beams for skyscrapers–mandate the rigorous and heavyweight processes implied by the term software engineering. When things go wrong in projects like these, people may die. But I’m not sure about the necessity of the engineering model in the realm of the vast majority of software development: commerce.

Business software is, as the name implies, for the benefit of business, and as such is frequently initiated, funded, supervised, and monitored by business. But the process of constructing business software is also finagled, interfered with, undercut, unreasonably accelerated, and generally completely misunderstood by the very entities that rely on it. This is because many companies are driven completely (and often unreasonably) by short-term monetary concerns, and consequently are totally at odds with the kind of methodical and repeatable processes which McConnell proposes to take the software profession into its next phase of growth.

It seems to me that mandating some basic engineering education for our non-technical business professionals (who, by being immersed in technology daily are becoming more and more technical) might be at least as important as tightening up programmer education. Software developers are often fully aware of compromises in quality, and they also know where the implicit and explicit bad software decisions are chiefly made: in the business domain.

Certainly, there has to be a middle ground between the absolute chaos of many business software projects and the tight control of a NASA software effort. But this avoidance of the "in-the-trenches" reality of programming is a weakness of the book. McConnell’s reasoning is not flawed, nor is it too impractical, and many of the suggestions he makes are very valid and would improve the success rate of the entire industry.

But in the majority of software development environments, true professional programmers are not empowered to make the decisions required to bring those suggestions to fruition. If the non-technical business professionals in charge are to understand and promote maturation of the software development field, they need to be schooled a little in the subject themselves, with the focus on quality rather than cost-cutting. What’s more, progress seems to be marching backwards as the commoditization of development skills spreads, reducing short-term cost at the expense of long-term quality. Until that trend changes, I predict roadblocks towards the kind of professional growth McConnell promotes here.

Perhaps I also felt a little badgered by the refrain, that the bulk of us really should be licensed and official to be programmers. That seems like a good idea on the surface, but intuitively I have my doubts. After all, you can still get a bad haircut from a licensed cosmetologist, and with the dearth of qualified developers still projected to extend far into the next decade, why winnow the field so drastically?

In any case, After the Gold Rush has a place on my shelf, but I’m not sure between which two other tomes. I benefited from reading it, but not quite to the degree that I had hoped. If you have been in the software game awhile, it’s worth reading for some perspective about what you’ve seen and done—and for some ideas about how things might get a little better.

Related Information

Andy Tegethoff is a father, husband, musician, and professional developer living and working in the Atlanta, Georgia area in the United States. He can be reached through the developer.* editor.
RSS Feeds
Software Engineering Articles and Essays Feed Icon
Software Engineering Blogs Feed Icon
Our newsletter policy:
No list sharing of any kind.
No "special offers" from "partners."
No "webinars." No "Special Reports."
No junk.
A Jolt Award Finalist!
Software Creativity 2.0
Foreword by Tom DeMarco
Web developer.*

All content copyright ©2000-2006 by the individual specified authors (and where not specified, copyright by Read Media, LLC). Reprint or redistribute only with written permission from the author and/or developer.*.