When I first rode out onto the software range to write about the problem of “cowboy coders,” I had no idea what a hornet's nest I was poking. Cowboy coders are those industry denizens who denigrate discipline of any kind, spurning methods and models and management alike. They would rather quit than cooperate. The thought of designing before cutting code is enough to make them feel downright claustrophobic. My suggestion that these mostly male code punchers might learn from their more collaborative female counterparts triggered a dust storm of protests. The protesters, nearly all male themselves, accused me of everything from sexism to communism, so it should not be surprising that I held off returning to the subject for a spell. But circumstances seem to impel me once more to think about the untamed wilds of the programming frontier.
For starters, my younger daughter graduated from college. Commencement was filled with its Kodak moments. I remember particularly that swell of paternal pride as she received her degree in psychology, then the relief-filled realization that the last of a long series of distressingly large checks had been posted to the college. And I remember the commencement speech.
Commencement speeches are rarely memorable. They're usually either pious, platitudinous, or political; some particularly deadly ones may be all three. But Wheaton's new president had prevailed on a former Cornell colleague to help launch her first Wheaton graduating class. Carl Sagan filled his remarks with wit and intelligence and kept them brief. Inspired by the graduating class, only the second to go through four years of coeducation at Wheaton, Sagan started by looking at gender and behavior. He focused on women and men and the world they make for themselves by first turning the spotlight onto chimpanzees. Chimps, of course, are our genetic brothers and sisters; 99.6% of the active genes are identical in chimps and humans. The behavior of chimps and humans is not all genetics, of course, but neither is it all simply learned. Just as looking at our own parents can tell us something about ourselves, we can learn something about homo sapiens sapiens by looking in the mirror of our primate relatives.
When stressed by crowded conditions, male chimps grow increasingly aggressive and competitive, gathering rocks to throw and keeping other males at a distance. Sagan described a male chimp, arms loaded with rocks, confronted by a quiet female blocking his way. Slowly, gently, she pries open the fingers of his clenched fists and deposits the rocks on the ground, then walks away. For some males, this is enough, and they turn to other chimpish interests, but a few just don't get it. Slower to learn, they have to be gently disarmed a number of times before they get the message. It reminded me of some of the men I know.
Sagan returned from chimpanzees to the subject of people and the widely demonstrated differences in how little boys and little girls play, the tendency for women to promote cooperation where men are prone to compete. He wondered whether the world might be more collaborative if women had truly equal access to positions of power and influence. Not a few senators and token female CEOs, but an honest fifty-fifty split of the leadership pie.
And I wondered where Carl Sagan was last year when I needed him, when I was being pelted by troops of software chimps, males all, for saying many of the same things. I guess they must have felt crowded by talk of cooperative coding.
If all cowboy coders were lone rangers, they would not present so many problems. Many of them are darned good. In isolation, on self-contained applications, cowboys can turn in whirlwind performances. Even one or two on a larger team can spice up a development project. Managed with judicious attention to the software interfaces and personal connections, cowboys can add diversity in ideas and perspectives without undermining the integrity of the system.
Unfortunately, cowboys have been known to gather not only at rodeos and roundups but also at large software houses, where they create complex system software—with the emphasis on complex. It seems just possible that some of the slipped schedules and bug-ridden software that plague our industry might be related to the wild-hair programming practices of undisciplined cowboy coders and the maverick managers who encourage them.
Cowboy coders can be creative, no doubt. That's not always a good thing. In the system software on which everything else depends we want peerless performance and, at the bottom of it all, rock-solid reliability. Performance can sometimes be bought through cowboy tactics, but reliable software generally comes from the discipline that cowboys disdain. Code that's both fast and flawless requires the very best software engineering practices carried out with consistent rigor.
Lots of cowboys also means lots of code—whether it's needed or not. It means great quantities of unstructured code, conceived on the fly and created independently, all of it different, all of it with the unique stamp of some cowboy's personal style.
Imagine, if you will, trying to produce a major new operating system, not with a closely coordinated team of disciplined professionals, but with a couple hundred coding cowboys. It's tough enough to lead a small posse of cowboys. Imagine trying to manage a whole ranch full of them. It might take a lot just to get their attention.
Perhaps, then, we should sympathize with the head of the Windows NT project who harangued his herd continually and even reportedly punched a hole in an office wall. Maybe as an ex-programmer with a reputation for clever code he understood the maverick mentality.
Alas, understanding may not be enough. As described by the Wall Street Journal (26 May 1993), the entire project seemed doomed to produce a gargantuan, overly complicated, and defect-ridden result. With some 200 programmers furiously cutting code to specs generated on the fly, the project promoted a cacophonous free-for-all.
Like the cattlemen and sheep herders of yore, coders and testers were turned into competing camps, pitted against each other in pitched battles. Such a division of labor can be effective in reducing software defects. But in the project pecking order, coders—mostly male and mostly cock-sure—came first. When coders complained that testers were trying too hard, the testers were overruled, presumably in the interest of meeting deadlines or performance goals.
With schedules slipping and problems proliferating, the NT staff went into “ship mode”—and stayed there for nearly two solid years. Since error rates rise when humans are fatigued and stressed, long hours under pressure will only multiply the number of defects injected into code. Some weeks they were finding and “fixing” on the order of a thousand bugs. But, even the best regression testing protocols detect only a fraction of injected bugs. The undiscovered residue of all those long weekdays and weekends awaits future users.
There are alternatives. Discipline works. As reported by Al Pietresanta at the 1989 Software Development Conference in Boston, by using “clean room” coding techniques and continuous process improvement, coding defects even in very large systems can be cut to less than one in ten thousand lines of code.
Maturity pays off. Large projects carried out by mature organizations using mature processes have been found to cut development costs by factors of 20–30 compared with more free-form hack-and-slash approaches.
There may be many bastions of coding cowboyism, but in the case of Rancho Redmond, it's now a matter of record. Mitchell Duncan, chief builder on the NT project, is quoted by the Journal as saying, “We have all these cowboy developers, just slinging code like crazy.”
And sling they did—4.3 million lines worth. Just be careful where you step.
From Software Development, Volume 1, #10, October 1993.