A 1960s personality-type coming back . . .

Cowboy Coders versus
Disciplined Programming Organizations

Conrad Weisert
December 21, 2010, ©Information Disciplines, Inc., Chicago

NOTE: This article may be circulated freely as long as the copyright notice is included.

A 1969 management edict

"In reviewing recent project work, I've discovered that certain programs developed by our staff employ COBOL's PERFORM verb to invoke out-of-line code. This technique obscures the program logic and makes source code listings hard to understand.

"In the future programmers are not to use non-iterative PERFORM (or any similar subroutine or macro facilty in any programming language) without my specific prior authorization. "

—newly appointed manager of a corporate Information Systems group having a staff of three-dozen programmers, 1969.

Not-so-ancient history

Today's reader is appalled by the sheer ignorance of the above and by the destructive impact that it was sure to have upon application software quality in that organization. The new boss explained that a program should be "sequentially readable". When he came to a reference to a subroutine that was defined on another page, he felt forced to interrupt his sequential reading and switch contexts, losing his thread of concentration. We tried to explain to him levels of detail, but he was unmoved. Fortunately he soon abandoned the notion of trying to read his employees' source code, and the edict was eventually forgotten.

We're dismayed to encounter similar attitudes today. Surprisingly, they come less often from an unqualified new manager than from an experienced individual programmer!

The key word there is "individual". We're seeing a steady increase in the phenomenon called cowboy coding. It's unclear what this style of software development has in common with cowboys, but the term is widely understood to describe a highly individual approach based largely on avoidance or outright rejection of:

It's as if we had returned to the 1960s, when such attitudes were common!

A recent encounter

Last week I got drawn into a silly argument with an earnest young man about programming standards based partly on this September article and even more on E-mail follow-up to this December one. In one note he proclaimed that he would quit a job and seek employment elsewhere if his employer demanded that he comply with the organization's programming standards.

He didn't really mean that, of course. He was presumably referring only to some arbitrary standard with which he disagreed, perhaps an unenlighened management edict like the one above. I referred him to my paper on highly participative methodology development, which I thought would reassure him that we were on the same side, but he continued to express his strong disapproval of programming standards in general, and I ended the unproductive exchange.

But then it turned out that my young correspondent didn't really disapprove of all standards. He firmly informed me that my own code exhibited techniques that should never be used in a C++ program! That sounded a lot like that old management edict!

An old stereotype

It's an old joke among methodologists that any practice that becomes part of an organization's written methodology:

  • should be a mandatory standard if I like it. (Comply unless you get prior permission to deviate.)
  • should be a flexible convention or guideline if I don't like it. (Use your own good judgment whether to comply.)

Although that's a too common attitude, this was the first time I had heard anyone threaten to quit a job if he was expected to comply with his organization's programming standards.

Inhibiting creativity? Never!

When organizations first began to recognize the need for some programming standards, we heard occasional protests from loners worried that the standards would thwart their brilliant original work. Indeed, some organizations did get carried away with standardizing everything in sight, issuing dozens of inflexible standards without staff participation. I showed a bunch of examples of such ill-advised standards several years ago.

As we probed, however, we discovered an interesting phenomenon. The programmers who expressed the greatest concern about their creativity being inhibited by standards, were worried not about being creative doing new original things but rather about being "creative" doing the same things over and over. A COBOL programmer who had figured out (or thought he had) the logic of Update Sequential File from Sorted Transactions was so proud of his accomplishment that he was eager to repeat it whenever an application required it. The last thing he wanted was to be told to use a standard library subroutine when the application called for updating a sequential file. Today we often see the same combative defensiveness among our cowboy loners, whether they use Java, C#, or some scripting language.

Experience has clearly and repeatedly shown that:

Enlightened management welcomes creativity on the part of its creative staff. But they also know the difference between creativity and anarchy.

Another old cliché

Cowboy coders sometimes assert triumphantly:

"A bad standard is worse than no standard at all."

That sounds like common sense until we think it over. If through the normal process of defining its methodology an organization should somehow adopt a shockingly misguided standard, like the silly edict at the beginning of this article, it will instantly draw the attention of the programming staff and middle-level managers. In any reasonable organization, that will trigger discussions that lead to repeal or replacement of the ill-advised standards.

On the other hand, when there's no standard to cover a particular situation, each programmer in the organization will devise his or her own technique. Some of those techniques may be superb, some may be atrocious, but all of them will be unpredictable and mutually inconsistent, adding to the aggregate cost of future software maintenance in the orgnization.

Would I hire a cowboy coder?

I've had occasions to interview applicants who clearly fell in the loner or cowboy category described above. The key question was: Can such an uncooperative individual also be a good programmer, i.e. one whose high-quality results would make a positive contribution to our organization?

It's certainly possible. But so far, the correlation between the cowboy mentality and very poor code has been close to 100 percent among candidates I've looked at. The deciding evidence has come from examining actual samples of their work. Each time I hoped to find a nicely organized, well documented, and efficient solution to a clearly-stated problem. Alas, so far, that hasn't been my experience. Colleagues whom I respect report the same findings.

I'll still try to keep an open mind, but after encountering a long series of examples, I'll be very surprised to find an excellent programmer with cowboy attitudes.

In any case our interview would end instantly if the applicant should assert that having to comply with our organization's programming standards would cause him to seek employment elsewhere.

1—"Best" in terms of both productivity and quality of results.

Return to IDI home page
management articless

Last modified March 28, 2011