The millennium arrived and you didn't even know it! Software reliability became, at long last, a reality. And how was this breakthrough in software engineering achieved? I quote from a 16-page marketing blurb from Nanomush, Inc., mailed to millions of benighted users and developers: “One of the most powerful additions to Blerbbleflox 3.1 is 'parameter validation.' Parameter validation means that when information is passed from an application to the Blerbbleflox operating system, Blerbbleflox checks the information to make sure it is valid.” What a novel idea! Why didn't you think of that, eh? (Of course, everyone knew I was talking about Microsoft and Windows 3.1. LLC).
This bit of attempted self-congratulation revealed that Nanomush, one of the world's largest developers of languages and operating environments, had finally begun to practice the rudiments of sound software engineering, techniques so basic that those worthy of the name programmer have known and practiced them since shortly after they learned to code. Could this cast some light on the shortcomings of earlier releases of similar software? But we should rejoice rather than carp, lauding the efforts of all fledgling software engineers, encouraging them to continue to mature, perhaps even to try to learn about coupling and cohesion or information hiding.
One wonders how the computer world arrived at this sorry state of affairs in systems software until one looks more closely at the character of the developers responsible for some of the products on which we depend so much. My colleagues who deal with organizational dynamics would call them “cowboys.” Cowboys, the last of the rugged and untamable individualists, are found in various fields, but nowadays many of them are punching assembly language cattle on the silicon frontier. Please note that the sobriquet ends in “boys” not “men.”
In the spring of 1992, at Miller Freeman's Software Development Conference, I found myself part of a panel on the putative topic of “structured” versus “unstructured” management of software development. I was paired with one of the development managers from Nanomush. His position, wholly on the side of the cowboys, was that what kept programmers from reaching their full potentials were managers who tried to impose standards, expectations, or restrictions. Just get out of the way and let them programmers do their thing. Structured methods, disciplined development, paper-and-pencil model building, and software metrics are all unjustified impositions on the free artistic expression of our brilliant programming cowboys. No wonder there is such unpredictable performance and variability in quality within the products being shipped by such companies.
Why does it take four releases and 12,000 (no kidding) beta test sites to discover that something less cryptic than “unrecoverable application error; okay?” is needed? But cowboys don't like to be reined in by specific quality criteria or by being expected to think out in advance what is really needed. No, let's just jump into that old development corral and cut some code, wranglers! The GUI may be pretty and the coding clever—after all, we are artistic geniuses—but to hell with real usability or reliability; those might require planning or, heaven forbid, discipline.
And we need not single out any one software company in this regard; the market abounds with countless examples. It is rare, however, when promotional literature or panel presentations give us such candid glimpses into the maturity of developers and their development methods.
Maturity is a central issue for the field of software development. Methodologists are wondering how long it will take for software engineering to mature as a discipline, managers are concerned about the level of “process maturity” in the approaches to development used within their organizations, and project leaders wonder about the maturity of the individuals whom they are called on to lead.
One large corporation surveyed their software development groups to determine how much and at what level of sophistication groups were making use of established systematic or disciplined software engineering approaches. The most advanced in their use of software engineering methodologies were the MIS and business information departments. Engineering support groups were intermediate in their use. Rock bottom last were—you guessed it—the people who wrote the operating systems, compilers, and utility software. Surveys of CASE tool penetration show similar patterns. Where engineering discipline and process maturity count most, software development is a wild-west side show dominated by coding cowboys.
Our culture lionizes the lone genius who does everything from start to finish on the development of some brilliant theory or machine or piece of software, but the truth is, nobody really makes it on their own. Even the eremitic teenaged hacker, cranking out code in the isolation of his bedroom on the machine he assembled himself, is dependent on the army of engineers who designed and built the chips, the legions of programmers who went before to create the tools. For those who are monitoring my LSI (Latent Sexism Index), it is not accidental that I use the masculine pronoun here. Most young hackers are male, and the particular mentality associated with cracking on-line computer systems or hacking clever new worms to bring networks to their knees is almost exclusively a male psychopathology. Boys also commit the majority of vandalism, and let's face it, writing viruses or trashing corporate files or invading government computers is just vandalism, nothing more. Unfortunately, it is only a matter of time before such computer vandalism results in loss of life; we've already come close on several occasions.
So, how did we get, in just a few paragraphs, from software engineering and methodological maturity to these gender issues? Because, at the heart of it, the immaturity of the cowboy mentality that shuns discipline and collaboration alike is largely a male thing.
At one meeting of a planning group within a software company, the assembled “team” went through 40 minutes of the men playing competitive games, debating definitions, jockeying for position, showing off their knowledge and erudition, and generally trying to score points off each other. Slowly, one by one, the men drifted away, excusing themselves with one rationale or another, usually something ostensibly “more important” having to do with “real work.” When only women were left, one of them said, “Now, we can get something done.” They wrapped up the real job of the meeting quickly and efficiently, while enjoying themselves in the process.
Of course it's a stereotype, but let's face it, guys, women understand collaboration a lot better than we do. For whatever reasons, little boys compete and little girls collaborate. Females, as a rule, are much better at building relationships, supporting and motivating each other. (So, one wonders why more of them aren't managers and project leaders in our field. Think about it, you middle and upper managers: all other things being equal, a female may have a decided edge over a male as a team leader—even with those Neanderthal programmers who claim they can't work for a woman.)
In my years as a marriage and family therapist I came, reluctantly, to the conclusion that most modern men basically do not know all that much about parenting, or, for that matter, relationships in general. This is not a matter of male bashing, just one of those statistical facts of life. I've been lucky to know uncommon males who really understood about relating, and I've also known my share of interpersonally inept females. Neither sex has a monopoly on either sensitivity or relationship bungling. But the odds favor women, at least in most cultures, when it comes to finesse with the people issues.
Now I expect to hear it loud and long from all those coding cowboys out there who insist that rugged individualism and the free market of programming independence are the only hope for American business (or humankind, if they're less provincial in their outlook). These are precisely the ones who insist that working collaboratively cramps their style, that building consensus drags them down to the lowest common denominator, that having to design before they code slows them down. Strange that so many of them produce such ordinary software or even fundamentally flawed systems.
True, there are some scattered few, women and men alike, with the genius, the vision, the talent, and the creativity to go it alone and do credible and laudable work. For most of us, though, releasing our real potential lies in learning how to build off each other's ideas in a creative synthesis that goes beyond what each of us might be capable of doing alone. Our work is likely to be better than either my work or your work.
So, grow up, cowboys. Learn how to stand on each other's shoulders instead of each other's toes. And, please, all the women out there, lend us a hand. We have so much to learn.
From Computer Language Magazine, Volume 9, #8, August 1992.