As time passes, only COBOL lasts

I heard that statement from Trygve Reenskaug over 20 years ago at a conference, and amazingly it is still true. New Jersey is trying to hire COBOL programmers to fix a 1980’s vintage unemployment claims processing system.

Supposedly due to have been replaced shortly after the Y2K issues, the system is still operational and in need of a few good COBOL Programmers.

It took a bit of searching, but I mentioned Trygve Reenskaug in an InformIT article I wrote all the way back in 2002 on “Design for Maintenance”.

The sorry state of software in many organizations is attested to by the way that people talk about “legacy systems.” Nobody seems to be excited about working on a legacy system, even those that are mission-critical or that handle the bulk of an organization’s revenue stream. Sometimes it seems as if no one wants to work on legacy systems, except maybe as a precursor to replacing those legacy systems.

The problem is that many organizations have let their mission-critical systems fall into an abysmal state where nobody in the organization really understands these legacy systems any more. Even worse, the organizations have failed to train their developers in the technologies they need to know to look after these mission-critical applications. No wonder it takes forever to get a simple change made on these mission-critical systems—nobody in the organization knows how to write COBOL. It would be laughable if it weren’t so sad.

As Trygve Reenskaug once said, “As time passes, only COBOL lasts.” The reality is that in the 1970s and 1980s lots of mission-critical applications were written in COBOL or similar vintage languages such as Assembler, FORTRAN, PL/1, and RPG. Even now, in the age of the Internet, Java, and web services, most companies are still dependent on applications written in these “legacy” languages. The Y2K fiasco didn’t kill off all these mission-critical applications; they’re just as important as they ever were.