A long overdue update to legacy computer software?

 

Way back when, in the 1970's and 1980's, I programmed computers in COBOL (among other languages).  COBOL, or Common Business Oriented Language, ruled the commercial computing world back then, with millions upon millions of lines of code written every year.  Many of the older, so-called "legacy" systems that are the computing backbone of large businesses were written back then, and have been maintained and updated (with greater and greater difficulty) ever since.

I'll give you a brief example.  In the early 1980's I wrote the so-called "price book" program for a big oil company in South Africa.  This program calculated the current price for every single product they sold - something like 4,000 different items, at the time.  I wanted to make it modular, with a separate program for every major group of products, to simplify maintenance and reduce the amount of time it would take to update the thing.  I was told that would not be acceptable:  I had to write a single monolithic program, calling in sub-programs and sub-routines whenever needed for specific product groups.  I did as instructed, and produced a program with several thousand lines of code.  I had to file detailed work flow diagrams for each major product section, showing which routines were called from outside and which of those routines served multiple product sections, so that a modification to one of the latter might affect one or more of the others (all of which cross-references had to be tested after every modification).  I warned at the time that this might become a maintenance nightmare, due to its sheer size and the number of modifications and updates that might be required.  I was told to shut up and get on with the job.  I obeyed orders.

When last I checked, some years ago, that price book program had ballooned in size to well over double the original length, and a team of three programmers were kept busy doing nothing but maintenance updates.  So many of the latter came in that one programmer would be finalizing an update and putting it into production, another would be midway through implementing another, and a third programmer would be picking an urgent change order out of the incoming pile to start yet another update.  The various additions, edits, alterations and mutations had added so many odd lines and sections to the coding that my original flow charts were almost unusable.

That's COBOL for you.  It was a very strong, stable business computing language, but it was clunky and maintenance-intensive.  Trouble is, very few people use COBOL today.  The old farts like myself who remember it are mostly retired and dying off, and the youngsters today want to use the "cool stuff" like C++ and other fancy tools.  I'm informed that a skilled, experienced COBOL programmer can almost write his own ticket in data processing today, just to keep the legacy systems running.  I know one formerly retired COBOL senior programmer who was tempted back to work with a package of well over $150K per year.  He smiles all the way to the bank.

That being the case, Anthropic claims to have developed an AI system that can update legacy COBOL systems, convert them into modern coding languages, and replace the old systems with the new.  This means it will have to read and understand COBOL (not always an easy task with rambling, much-modified legacy coding), break it down into more understandable chunks, rewrite each chunk in modern computer languages, test them for accuracy, produce easy-to-understand flow charts or other technical documentation for each of them, and gradually replace all that clunky stuff with modern software.

That ability is very long overdue.  If it works (and I'll want to see lots of evidence of that before trusting its output), mainframe computer manufacturers such as IBM may be drastically affected, because modern codes and languages can run efficiently on much smaller computers.  Modern computer hardware is being optimized for such use:  see heterogeneous computing for more information.  The Apple computer with its M-series chip that I'm using to write this article is just one example.

If you'd told me all those years ago that the COBOL code I was writing would still be in production use over half a century later, I'd have laughed at you.  Guess COBOL and corporate inertia are having the last laugh . . .

Peter