David Barth on Cobol

David Barth on Cobol

by David Barth, 2004

I worked on a team converting software applications (apps) so that they would work correctly at the beginning of the year 2000 (Y2K) for a company Denver, Colorado, USA. Our work went very well with no problems at the turn of the century.

A couple of years after Y2K, the company's management decided that Cobol was outdated, and that Oracle apps could be put in place quickly and efficiently to provide the same functionality as well as even more functionality. The company management, like most management teams, assumed that this concept was absolutely true and that this would be an easy fix [mistake number one]. After all, rarely is a seasoned information technologist promoted to a high management position that enables him or her to provide insights and reality checks to the uninitiated managers.

To save money, the company hired an outside vendor to come in and rewrite their apps in Oracle. Oracle's bid was too astronomical to consider them to do the rewrite [mistake number two]. The worst thing to do is to save money by bringing in a third-party software group to rewrite code in a language (Oracle) in which they are not intimately involved and do not have resources within the company providing the software. The selected vendor promised that the work would be done in a year and the company believed this to be true [mistake number three].

Furthermore, the company decided to save money by not doing a lengthy parallel whereby the new system would run along side the old system so that comparisons could be made and the new system could be evolved to match the critical features and functions of the old, Cobol system. What the company management decided to do was to have the new system written based on the specifications of the old system, then do a cutover so that at the end of a Friday, the company staff would finish their tasks using the old, Cobol system, and on Monday morning they would fire up the new system and do their tasks using it [mistake number four].

At the end of the first year, the software group doing the rewrite begged for six more months. Six months later, it begged for another six months. The company was bleeding big bucks to pay those 35 rewrite guys, and after two years, the company management said install it, bring it live, and get the hell out of our house because we can't afford to go into the third year of rewrite [mistake number five].

The group rewriting the software was never teamed with company users who could guide and advise the rewrite guys on whether they were providing the necessary functionality [mistake number six].

Well, the apps were cripple-ware. The new system had nowhere near the same functionality or ease of use that the old, Cobol system had. Over the next five years, the software was improved by company software guys, but compared to the original Cobol, it is a train wreck. This was not the fault of Oracle which has a flag-ship database and data management system that is used successfully, around the world. The problem was that the company management wanted to move to a new software platform (Oracle) and away from the old sofware platform (Cobol) as quickly and cheaply as possible. Why? Because everyone else was doing it, and in this era of fast-moving technology, going away from "ancient" Cobol seemed like the thing to do.

Converting from an existing language (Cobol, in this case) to a "new" language is a tough row to hoe. No company should try that trick without a lot of study, a lot of money, a lot of time, and some luck.

When Grace Hopper described Cobol to somebody many years ago, the person said, "But Grace, then everybody will be able to write programs!" But that was Cobol, and now Cobol is dead, having been replaced by arcane, voodoo-like languages.

I asked a C++/Java programmer how he did maintenance on code that has thousands of lines of gibberish code that looks like "i(r,q,m)x". He said they carefully determine where the offending code is, surgically remove it, and rewrite the new code from scratch because existing code is not maintainable, let alone readable or understandable. And, of course, the new code is not maintainable, let alone readable or understandable.

Once the bugs are worked out of an app, maintenance is in direct correlation to changes in company policy and procedures. Maintenance that is designed to keep an app up-to-date is necessary, regardless of the language it is written in. A company that freezes the functionality of its apps can reduce or reassign its maintenance staff, but most companies don't want to do that. They want to continue to improve and fine-tune their software systems, a laudable concept, but one that, to be effective, has to use a software language that is maintainable, or it will be costly to find people willing to work on it, and it will be costly in the amount of time required to make the alterations.

The problem with C-based languages like C++, Java, C# [C Sharp], and VBA is that there is no language reference for them because there are a zillion ways to write code. And, that code is all in shorthand, so it isn't self-documenting like Cobol is.

These languages, as well as VBA, are descendents of C, which was developed by some guys at Bell Labs who had too much time on their hands. They didn't expect or want that sort of shorthand code to be used to write massive apps. They wrote it so that they could do little, quickie programs without getting "writer's cramp" that could be caused by the self-documenting features in Cobol that require additional information to be embedded into the code.

Now, we have these huge, monstrosity software apps written in Java and C++ that, someday, will fail massively. I think we have a long way to go before we will have a way to write code easily, as we had with Cobol. At least with Cobol, you could read it, understand it, and maintain it, if the original programmer did his job right.

"Object oriented," was a buzzword that ignorant managers jumped on and decided they had to have, even though they didn't know what it was, or how it worked, or how it would affect their software apps. Cobol was given object oriented capability by Fujitsu, but it was too late. Cobol was considered "old stuff, unworthy of use" by nearly every corporate manager.

So, here we are with gobbledegook C++, Java, and VBA code that is difficult, if not impossible, to read, understand, and maintain. I took three college classes on C++ and Java, but I didn't get much out of them except a feeling that we've gone backwards as far as programming goes.

I had a project a couple of years ago to write some VBA software to reformat Excel spreadsheets. I bought $100 worth of books about VBA so that I could write the code I needed to reformat billing statements. I soon found that the books were worthless, and the only way I could find out how to write it was to do Internet searches. And sure enough, there were guys out there who had put up blogs saying, "Hey, I accidentally found out how to do such-and-such, and here is how to do it." Thank goodness for those guys. I found the code I needed in about a dozen different Internet locations, and was able to complete the project. No one else on the planet can read that crap, but it works!

Intercom, the magazine of the Society for Technical Communications, has a technical glossary that describes C++, C# [C sharp], and Java as follows:

"Three variants of a single programming language [C] in which it takes longer to create a printout of the phrase 'Hello World!' than if you were to carve it in stone with a hammer and chisel. Industry critics believe these languages single-handedly ended efforts to make computers serve humans rather than vice versa."