The Y2K Noncrisis

The Y2K " Noncrisis "

I have saved for last the most important reason perhaps for COBOL's continuing excellence: the superior maintainability of COBOL applications.

Much of the criticism of the COBOL language within the application development community is aimed at its "wordiness." It is true that COBOL is verbose. COBOL applications often require more lines of source code to be written than are necessary in applications written in other languages. This was by design. When the original members of the CODASYL COBOL committee set out to define the syntax for this Common Business Oriented Language (COBOL), they intentionally included many clauses, phrases, "noise words," and so on not to make the job of the development programmer harder, but rather to make the job of the maintenance programmer easier and the results more accurate. COBOL instructions such as "ADD this-weeks-salary TO previous-year-to-date-salary GIVING new-year-to-date-salary" are indeed more verbose than, say, "LET z = x + y." But no one can argue that the meaning/intent of the business logic coded in the former example is much clearer than in the latter example. This is by design. In application development, clarity, not cleverness , is a virtue .

COBOL contains syntax for coding its own shortcuts and clever programming techniques if a programmer is so inclined. The COBOL statement COMPUTE z = x + y is perfectly valid, but it is antithetical to good COBOL programming practices and is discouraged for all the reasons mentioned previously. Is this really important? You need only reflect on the Y2K "noncrisis" at the turn of the new millennium to determine how important this is. Many people blamed COBOL for the Y2K crisis, pointing to the huge number of legacy (read again: COBOL) programs still running on computers in o1999 as we prepared for potential disasters when switching over to o2000. This argument is fallacious. As any good application developer knows , the problems created by storing dates using the last two digits of the year (e.g., 85) instead of four digits (e.g., 1985) resulted from shortsighted system design, not from a poor choice of the programming language used. All applications (business applications and others), whether written in COBOL, Fortran, C/C++, or Visual Basic, had to be checked and modified to deal with the change from o1999 to o2000.

It's my firm belief that the Y2K crisis, anticipated by so many, turned out to be a Y2K "noncrisis" specifically because most of those legacy systems were in fact developed with COBOL. Because the COBOL source code is written with so much more clarity than source code written in other languages, the huge task of reviewing all of that legacy source code and making changes when/where necessary was made much easier because of COBOL than nearly everyone had expected. True, the Y2K crisis was a tremendous problem for the IT industry. But the efforts involved to fix the problem were made much easier, not harder, because of COBOL, not in spite of COBOL. In a way, COBOL turned out to be "too good." The clarity associated with COBOL source code made those earlier COBOL applications much more maintainable than anyone had predicted . After all, why discard an application that's performing most of its business functions properly simply because that application needs updating, when modifying the original source code is easier, less expensive, and adds years of productive life to business systems? As a result, the lifespan of legacy systems was stretched much further than people (systems designers) had expected. Is this bad? No, I think not; it's shortsighted perhaps, but it's not bad.

What we learned from the Y2K crisis was that COBOL provides "health insurance" to corporate assets. That is, it's the best way for an enterprise to protect its investment in its IT assets. The same can't be said for applications written in other languages. In many cases, applications written in lower level languages (assembler) or other third-generation languages (C, Pascal, and so on) were simply not worth deciphering to fix Y2K (and other) problems. Instead, many were discarded and replaced by newly written programs (hopefully in COBOL, but probably not).