©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.
—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.
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:
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.
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?
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:
"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.
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.
Return to IDI home page
Last modified June 2, 2012