Cobol, The First 50 Years
In case you need to be reintroduced...
Along with Fortran and Lisp, Cobol was one of the three seminal programming languages created in the 1950s. Developed in 1959 by a team led by Grace Hopper and approved in January 1960, Cobol is characterized by a verbose English-like syntax and a strict hierarchical program structure. The language standards specify the handling of decimal currency data more fully than any other language. Cobol was designed for business data processing and remains the quintessential language for that purpose. (Cobol is an acronym for "COmmon Business Oriented Language.")
The Gartner Group has "maturity-rated" all programming languages as:
- Adult (actively evolving)
- Mature (active, in general use)
- Aging (think Pascal)
- Elderly (end-of-life languages like VB6).
By Gartner's definitions, current Cobol variants are not, as you might think, Elderly, or even Aging, but merely Mature.
Hopper handed over governance of the language to ANSI, which helped its wide adoption. The current Cobol standard is Cobol2002, supported by, for example, IBM's Enterprise Cobol (www-306.ibm.com/software/awdtools/cobol/). Cobol2008 is in the works.
A Quarter-Trillion Lines of Code
To say that Cobol is widespread is an understatement. In 1997 the Gartner Group estimated that there were 240 billion lines of Cobol code in active apps. Something like 90 percent of financial transactions are processed by Cobol code, and 75 percent of all business data processing is Cobol. Merril Lynch reports that 70 percent of its business runs on Cobol apps. Five out of eight companies with an IT manager use Cobol, most of them using it a lot. One estimate puts the value of current running Cobol code at $2 trillion. (In addition to the Gartner Group, some of the above figures come from Computerworld, Ovum, and Micro Focus International.)
And it's not just legacy code. Billions of lines of new Cobol code are being written every year. Cobol apps are typically very large, a million lines being common, and partly for that reason they are also long-lived. It's cheaper to maintain the code than to replace it, and 40-year-old Cobol applications are often extremely well debugged (although anyone who was bit by the Y2K date bug, primarily a Cobol problem, might disagree).
Cobol Coders An Endangered Species
In fact, the code is outliving its coders.
As long-time Cobol coders die or retire, they are not being replaced. Few schools teach Cobol any more. And demand is still strong. If your business depends on Cobol, you are facing some choices. Whether you're actively developing new Cobol apps, just maintaining the old, or trying to move away from Cobol, you need Cobol expertise. You can: 1) keep your current Cobol programmers happy and employed while you scramble to wean your business off Cobol; 2) try to find younger Cobol programmers to replace those you'll be losing; or 3) push your current programming staff to learn Cobol.
Replacing Cobol entirely can be an expensive proposition, and many companies (and State governments) have for decades thought it cheaper to keep it. Still, many businesses are moving away from Cobol, or saying that they will if and when they can. Some big companies are replacing at least some of their legacy Cobol apps with packaged software from Oracle and other companies. But a quarter-trillion lines of code does not get replaced overnight. Cobol programmers are needed.
Micro Focus and IBM have tried to nudge universities to train more Cobol programmers, offering free courseware and technology, but this hasn't resulted in a huge flood of new Cobol programmers.
So adding Cobol to your toolkit does make you more employable. And you can definitely do better than minimum wage.
