After the Gold Rush: Creating a True Profession of Software Engineering (Best Practices)

The question of whether such a "professionalization" of software development is a good idea is up for debate, certainly. It seems that a lot of programming jobs involve standard problems and solutions, which would lend themselves to teaching and testing. On the other hand, quantum-leap innovation has often come from "cowboy" artisans who deviate from the standard practices. Similarly, aggressive technology investors aren't interested in deliberate, standardized work--they want world-beating products (and they want them to market immediately, if not sooner). After the Gold Rush makes a well-reasoned, well-supported argument for a more structured programming profession, and is worthwhile reading for any technology executive or project manager. --David Wall

Topics covered: The problem with "code-and-fix" software development, the elusive nature of a body of knowledge in high-tech subjects, the structure of more traditional engineering professions (civil, chemical, and others), solution design versus implementation, and suggestions for how software engineering professionals might get trained and certified.

The point of this book is not to tell you specifically how to develop robust software - that topic is covered in some of McConnell's other books. This is a call to action on holding software professionals to higher standards and making them take responsibility for the often substandard product they emit.

McConnell focuses on certification of software engineers. This is certainly worth exploring but I would like to have seen some discussion of other areas for improvement, such as automated testing and more systematic software reuse. Imagine you have to build the Golden Gate bridge by hand-crafting every rivet - that is the state of software engineering today.

Also we should not rush blindly into implementing certification programs. The prospect that a corporation could divert responsibility for its poor business decisions onto a certified software engineer, who simply tried his/her best to implement what the employer asked for, should give us pause. On the other hand, certification should ideally be an engineer's weapon in a death-march situation. If s/he could say "In my professional opinion, what you are asking for, given the time and resources available, is simply not possible", a lot of business fiascos might be avoided. In the end it's a question of educating both management and engineers about the differences between business decisions and technical decisions, and the responsibilities of each party.

I expect this book to play a useful role in getting a much-needed debate going.


Software Engineering as a REAL Profession?   April 19, 2002
 8 out of 8 found this review helpful

The Tar Pit. Software Dinosaurs. Fool's Gold. Orphans Preferred. Software Engineering is Not Computer Science. These are just a few of the chapter titles from Steve McConnell's latest book, After the Gold Rush. Perusing the table of contents gives one the impression that this read is going to be a hard-hitting call to action, and it doesn't disappoint.

After writing some of the best coding, management, and process books of the last decade, McConnell is calling for software development to join the ranks of other real professions as a true engineering discipline. I'm a civil engineer by education, and I can confirm that most software development bears no resemblance to the rigorous discipline exercised by professional engineers. We as an industry have been walking on the wild side for too long. It's time to settle down and get organized.

The book is a series of essays that take the reader from the problem, to the search for the solution, and finally to a plan for education and certification. Readers of the author's other books won't be surprised by the analysis of the problems facing the software industry. We--collectively--just put out too much bad software with too many bugs, are still stuck with the Not Invented Here syndrome, and aren't even focusing on the measures that provide feedback for improvement.

He promotes the Capability Maturity Model for Software (SW-CMM) as a measure of the practices in wide use today. The report is bleak, and makes software disasters like the Denver airport baggage system, as well as failed software upgrades at the IRS and FAA, seem inevitable.

The answer, in overly simplistic terms in this review, is to make software engineering a professional, licensed profession in the same model as civil, mechanical, and electrical engineering. Like those disciplines, this doesn't mean that every practitioner in the field must be educated and licensed as an engineer. But every software project must be signed off by such a professional, who certifies that the project was executed with the proper, rigorous methodologies and built-in safety factors.

Like the construction of a log cabin, there would be no need for every relatively simple software application to undergo such rigorous engineering. But any major application would be required to have an engineer overseeing the process.

This move is long overdue for the profession. Maybe with it, we'll eliminate the number of major software failures that constantly make the news, and software will once again be as reliable and trusted as the Golden Gate Bridge or the Panama Canal.


Bureaucracy is not the answer   December 5, 2001
 9 out of 29 found this review helpful

This book is mustly a repetition of ideas from his earlier Rapid Development and Code Complete. The section on ethics is naive and pathetic. The idea that because one has a software engineering license one is good is misguided. You can force someone to learn a few things including the basics of a discipline, but you can't ensure they are competent. The idea that a person would be legally responsible sounds like a way for corporations to pass the buck and evade responsibility and have a convenient fall guy. If I were a corporation and a "licensed software engineer" started making waves I'd politely but firmly explain the relities of the world (I'd threten to fire him if he didn't tow the company line, bureaucrats are easy to replace).

Whats needed is a broad recognition that software engineering is a discipline that should be required by CS majors and MBA working in an information science area.

What really needs to happen is upper management needs to be held accountable for their mistakes. Having a "licenesed software engineer" wont mean a thing.

The book offers little of practical value, other than a brief description of CMM and some general common sense ideas. For the money its of little value. I'd suggest Rapid development instead. Its much longer, but has real meat.