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
8 comments:
The last programming language I ever used was FORTRAN. Used to be that most scientific and engineering code was FORTRAN. Nowadays? I have no idea what they use.
COBOL did a good job at what it was originally designed for. It's possible to write code that is clunky and maintenance-intensive in just about any language. Anyone claiming otherwise is ignoring human ingenuity when it comes to being "original", as well as management's ability to turn molehills into mountains. One of my sundry jobs was COBOL programmer for a reporting team. Management's insatiable demand for more and more reporting...nightmare material.
The largest problem with updating any legacy system is the lack of a robust test suite.
No doubt there wasn't any such thing for your system, because higher would have seen it as a waste of time and money (like all the other things you suggested).
The first thing they should do with AI on any legacy system is to generate such a test suite. You *must* validate it, but that's like checking any AI-written code; it's probably much faster than writing the code in the first place.
Though tracking down what's supposed to happen on seldom-executed code paths may take a while.
Once you have confidence that you know just how the system is currently *supposed* to behave, it's much easier to change it. Either with AI or with humans writing the code.
COBOL systems definitely need an update but to make it work you're going to have to set up a parallel architecture for Anthropic to test.
You can't screw up financial records and just shrug and move on and even then there's a huge set of subsidiary systems and companies that work as pass-through to COBOL mainframes.
Hard to understate the changes and shifts this will cause, even if you had faith in banking IT which you shouldn't.
I spent year maintaining programs in IBM Mainframe Assembler. One speed-bump to the AI verification suite that I can see is that the source code can tell you what the program does--it cannot tell you why it does it. Legacy systems may be jumping through hoops to fulfil a requirement for a client that is long gone. Another (still current) client may be depending on some feature that is an apparent error. I can recall sitting-in on a discussion of such a case. The higher-ups had found a case in a piece of code where of cut-off value seemed strangely chosen. I pointed out that (from the comments) this area of the code had not been updated in five years. Did ww really want to shoot from the hip to change this value? That cooled the urgency of this update quite a bit.
thirty, forty years ago, we were saying that there were COBOL and Fortran programs running which had been compiled before the current batch of programmers were born.
It is possible to write spaghetti code in any language, and conversely it is possible to write structured code too. Back in the 90s I was working on an aerospace project and we had to use FORTRAN, but I was senior enough to force us writing fully modular code. We had separate code blocks for orbital mechanics, solar array performance (w thermals), Battery performance, and power distribution.
It sounds like your manager at the time was more interested in protecting his turf than following proper coding practices.
I retired last Summer from a software firm I had been with for 25 years. Most of the code I wrote for them was modular (i.e. Object Oriented).
Just before they told me my services were no longer needed, I was astonished to learn that others of the software team were preparing to update several HUNDRED pages of the web app because they wanted to change the way users were selected.
"What? We wrote an object you could drop onto any page to select users. It created a common user interface that was easy to maintain."
Oh, we replaced that ages ago!
It was a good time for me to retire.
Post a Comment