Ancient language continues to inspire misinformation . . .

Is there a COBOL brain drain?

©Conrad Weisert, Information Disciplines, Inc.,
1 June 2012

"He's concerned about finding new Cobol programmers, who are expected to be in short supply in the next five to ten years. But what really keeps him up at night is the thought that he may not be able to transfer the deep understanding of the business logic embedded within the bank's programs before it walks out the door with employees who retire."

:
:

"If you wait until that institutional knowledge is gone . . the costs can be as much as 10 times higher than they would have been beforehand."

—Robert L. Mitchell: "The Cobol Brain Drain", Computerworld, May 21, 2012, pp.19-25.

The potential disaster that Computerworld and others cite every year or two has less to do with knowledge of the programming language in which the legacy applications were coded than with an appalling lack of management disipline and understanding of basic documentation principles.

There is no such thing as a "Cobol Programmer"

A Cobol programmer would be like a Chevrolet taxi driver—not exactly a career calling. Not even in the years of Cobol's peak popularity did we hear of anyone getting a college degree in Cobol programming, nor are we aware of any personnel department that established "Cobol programmer" as an official job title.

For purposes of this discussion there are three kinds of programmer:

  1. professional programmers who are well acquainted with Cobol and use it comfortably,
  2. professional programmers who have little or no Cobol experience, but are well-acquainted with the procedural programming paradigm and could easily master basic Cobol in a week,
  3. and programmers who would be incompetent in any programming language.

If an organization has become dependent on undocumented, incomprehensible programs, it is the type c programmers and indifferent managers who are responsible. With all the warning they've been getting, they've had plenty of time to put priority on cleaning up their mess.

" . . decades of changes have created a convoluted mess of spaghetti code that even the most experienced programmers can't figure out. . 'Some systems are snarled so badly that programmers aren't allowed to change the code at all.'"

—Mitchell quoting a desperate executive

It's still not too late for most of them, but articles about "business logic walking out the door" won't motivate them.

This kind of alarm reminds us of the Y2K warnings a dozen years ago. According to executives and columnists the problem was no one's fault; it was a natural disaster.

Not a new insight

Expecting a company's IT or data-processing organization to follow sensible programming practices is not a recent development. The so-called "structured revolution" of the 1970s was supposed to put an end to incomprehensible programs and unmaintainable spaghetti code. Today's desperate manager very likely expressed satisfaction years ago at having the programming staff trained in the latest best practices and would reply affirmatively if asked whether the staff practiced the structured disciplines.

How, then, did those organizations manage to continue producing unstructured incomprehensible programs and then make them even worse with every maintenance change?

Misconceptions about Cobol

Four years ago we noted a number of popular myths about Cobol, and now Computerworld gives us another one:

The language is known for its scalability, performance, and mathematical accuracy.

Mathematical accuracy? Which programming languages fail to produce accurate results of numerical computation? In what way does Cobol do better? The author may have been thinking of Cobol's non-integer fixed-decimal scaling (PICTURE "S9999V99") for which some programmers unthinkingly substituted floating-point when they made the transition to another language.1

Finally, we're tired of references to Cobol's being "dated" or "obsolete". After a half-century can't we at last admit openly that Cobol was never an effective language for programming business applications? From the start Cobol:
  • encouraged a style of programming based on monolithic structure and mindless repetition,
  • facilitated the production of the maintenance nightmares that are still causing the anguish reported in Computerworld and other sources.
  • enticed, aided by exaggerated publicity, unqualified people to take up computer programming.

"The use of COBOL cripples the mind." —Edsger Dijkstra

Over the years Cobol and the poorly qualified programmers who used it have cost the world economies hundreds of billions of dollars if not trillions. Few knowledgeable programmers are sad to see Cobol come to a long-overdue end and to see hordes of incompetent programmers walk out the door, but not with application knowledge that they should have documented long ago.

Final word

Meanwhile, by all means clean up the undocumented spaghetti-code messes. If you don't reprogram them in another language at least convert them to clean, well-organized, understandable Cobol. In most cases the benefits will easily justify the cost.

1—Exact arithmetic on decimal fractions is built-into PL/I and some other languages and is efficiently supported by class definitions in C++ and Java.   Even a few respected authors are confused about this.

Return to IDI home page
Management articles

Last modified June 2, 2012