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
"In the future programmers
are not to use non-iterative —newly appointed manager of a corporate Information Systems
group having a staff of three-dozen programmers, 1969.
—newly appointed manager of a corporate Information Systems group having a staff of three-dozen programmers, 1969.
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!
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:
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.
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.
Cowboy coders sometimes assert triumphantly:
"A bad standard is worse than no standard at all."
"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.
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.
Return to IDI home page
Last modified March 28, 2011