After the Gold Rush: Creating a True Profession of Software Engineering
Product Description
In this newest addition to Microsoft Press’s acclaimed BEST PRACTICES series, award-winning author Steve McConnell offers candid reflections upon and a look ahead at the software engineering profession from one of the industry’s most highly regarded practitioners. AFTER THE GOLD RUSH is a collection of illuminating original essays on contemporary software development topics that highlight critical trends and call for a more rigorous and standards-based profession. McConnell delivers a lively and provocative narrative that aims to help software developers step back from the day-to-day rush of their work and think about where their careers-and the industry they’re helping to shape-are going.Amazon.com Review
Software developers are supposed to work insane hours, drink only caffeinated beverages, and have no personal lives, all in the interest of shipping the all-important Product. In the popular consciousness, the desperate programming team has acq… More >>
5 Responses
7.1.2010
Those that can: do; those that can’t: teach; those that can’t teach: audit; those that can’t audit: do process. This book is another plug for software process over technology. It will never happen in the real, budget contrained world. Keep up on ASP, Java, COM/DCOM, etc. intead of. For every job listing on Monster asking for SW-CMM, you’ll find 20 asking for a specific technology. Go with the odds.
Rating: 1 / 5
7.1.2010
Since the 1970s, books like After the Gold Rush have been frequent and unchanging. They notice that most software is developed using techniques that are apparently what the French call bricolage, rules of thumb rather than the more scientific principles of traditional engineering. They then urge greater maturity upon software developers.
What we need to realize is that software engineering is a science of man. Its mistake is to transfer the objectification of nature to human behavior, thereby becoming, in Nietzche’s sense, a form of truth/power and a tool for domination.
C. S. Lewis pointed out that Renaissance science was not so much a tool for the disinterested domination of nature as a magician’s tool for the control of people, and shortly after Lewis, Thomas Kuhn confirmed this from within the scientific establishment. Francis Bacon was not only a disinterested scientist but also heavily involved with the politics of his era and the desire of the Tudor magnates to bring England’s people under centralized control.
Nonetheless the software engineers believe, by reducing what they regard as the bricolage of the traditional computer programmer and by increasing the use of empirical tools and visual aids, software engineering will then succeed in the manner of traditional engineering. Power, they believe, will realize truth.
In the meantime, however, bricolage has continued to produce success. Linus Torvaldys’ bricolage proved that even operating systems could be fabricated by individuals with no power relations between each other.
The praxis of actual computer programmers varies widely. However, software engineering mavens think it’s all bad praxis which, they claim, should be more controllable by “normal people”, defined in America as management, and management-oriented.
“Normal” people seem to be those who more or less willingly adapt to a life structured in detail by power. To take one example, the “normal” software developer accepts without discussion the capillary power relation known as “going to work”, involving so often exhausting and meaningless daily drives from point A to point B in order to satisfy the undiscussed proposition that (a) the corporation needs to watch him work, because (b) absent this Panopticon, the employee would immediately assert the converse power relation known as goofing off. Of course, this misses the very idea, absent as it is from a network of power, that one might like to work.
Early programmers developed many techniques that newbies have yet to learn properly. Programmers were only accidentally members of a guild, and this “priesthood” steadily expanded. New monks may have been occasionally whacked upside the head for their own good, and users demanding the logical equivalent of cold fusion have occasionally been sassed, even when they were CEOs: the disruptive backtalk, not the bricolage, was the real problem.
Instead of a “priesthood”, there was that rarity, the career open to talents. Programming has long represented “some way outa this place” to people from broken homes, minorities and women. But after years of struggle, these folks find social relations unchanged, and they view top-down rhetoric about “software engineering” with suspicion and hostility. But because they don’t have the tools to organize these thoughts, this becomes a populist programming anti-intellectualism which is part of the problem set, and is marshaled by management to resist Steve’s goals.
It is simply not likely that even a licensed software engineer will be able to hold up a development project in the way that Steve describes, by refusing to sign off. Steve takes as frozen and given traditional professional/organization power relationships, including that of the doctor to his hospital or HMO and that of the lawyer to the megafirm, and Steve commits a naturalistic fallacy, for for the same reasons programmers cannot seem to professionalize, doctors and lawyers are being steadily reduced in power by the same forces programmers face: those of cost accounting and naked authority.
The programmer will always represent a scandal: the scandal he represent is so unspeakable that it only appears in old myths including the Nibelunglied with its account of the relationship of systems (the laboring gods who built the palace of the new gods and who wanted to be paid.) To be second nature, the administered world has to break this nexus and it has and will use all methods up to and including liquidation of programmers as a class; for example, researchers have found that many “programmers” spend their days doing anything but writing code.
Steve does not have much respect for computer science which to me is closer to original programming praxis and he feels that enrollments are declining in CS because the so-called “market” of prospective students shrewdly perceive writing compilers and learning graph theory as valueless. This ignores the fact that this market by definition doesn’t know what it needs, and it also ignores the fact that many software products are indeed at some level formal languages. Their use demands at a mininum an appreciation for what Dijkstra has described as the cruelty of symbolic manipulation. Their fabrication does indeed involve at various times the writing of compilers and the understanding, at the level of theory, the idea of graphs.
The “software engineer” may very well go to work believing that computer languages from SQL to various fourth and fifth generation proprietary languages are now so powerful that they understand, in the manner of human languages, subtle shades of meaning and all stupid errors. But these folks will also, courtesy of lack of humanistic culture, fail to grasp just how vast human capability for nondenumerably large shifts in meaning can be.
They will be, in other words, modern barbarians of an administered world that will not see what it is about, and that will regard human creations blasphemously as a second form of nature, more controllable by empirical techniques than by logical analysis. What will result, and what has already resulted, is more domination of man by man, and more “I’m a software engineer, and you’re a mere coder.” Steve, after Code Complete, I expect more from you.
Rating: 3 / 5
7.1.2010
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.
Rating: 1 / 5
7.1.2010
Like all his books, it seems that Steve McConnoll has read and digested everything written on the subject before him. It’s a bit of a tome but you’ll find issues covered here you never thought were relevant but turn out to be of quite fundamental importance. If you want to extract ‘professional’ software development from the hands of cowboys, this book shows how to go about it.
Rating: 4 / 5
7.1.2010
Steve McConnell’s book is certainly well researched and well written compared to most “me-too”, thrown together computer books.
There seem to be a couple of logical flaws in his arguments. The first, as noted in another review, is that making software engineering a profession like law and medicine may be only half a step forward, considering the high tolerance for error and high resistance to change in those professions.
The second apparent flaw is in his logic on the economics of defect removal. He cited studies that showed it’s actually cheaper to develop software the more defects you eliminate. But then he adds (my paraphrase) “of course eliminating any _more_ than 95% of the defects is bad business.” He didn’t cite any studies to support this magic qualify cutoff.
In contrast, one of the main practices of XP (Extreme Programming) is 100% defect removal.
I notice the book is published by Microsoft Press and Microsoft is notorious for poor software quality so perhaps McConnell’s assertion that a 5% defect rate is optimal comes from Microsoft’s culture.
Certainly a book worth reading if you are interested in the future of software development.
Rating: 4 / 5