During her time in the Navy, Hopper was one of the first people
to program the Harvard Mark I and its successors
Post peak Java play
As the shoulderpads of the '80s gave way to scarily sharp haircuts of the '90s and COBOL became Cobol, the old order started to break down. It was not so much because of any change in supply and demand, but rather that a critical component of what you were paid was the fear in the heart of your bosses at the thought of you leaving – which is not exactly the same thing. Cobol was seen as “yesterday” and so employers felt with some justification that they didn’t have to pay so much to keep their Cobolers sweet.
This was in some small part my fault: I started writing about this cool new Visual Basic thing. It allowed you to knock up pretty GUIs, putting lipstick on the server and mainframe pigs – meaning bosses saw lots of “visible productivity” – while a lot of Cobol (+Fortran, REXX, etc) developers saw their future in PCs. Since BASIC started off life as a dumbed-down Fortran, they found it easy enough.
A standard trick in writing CVs is to “compress” older skills so as not to “confuse the message” that you’re fully into whatever is fashionable this season, which meant the visible number of programmers who knew Cobol dropped like a stone just as we were all gearing up for the Millennium Bug beanfeast, making it all the more lucrative.
So on the 50th anniversary of the S/360 Mainframe, the Cobol world is now largely divided between IBM building its compilers for its hardware and Micro Focus, which covers pretty much everywhere else.
I got lots of crap for calling “peak Java pay” a while back, pointing out that the supply of Java programmers was ever increasing, but that the demand was not infinite – meaning more programmers each earning less as the ratio moved against them.
Talking to IBM and Micro Focus, there is a good argument that precisely the opposite is going on. We’re now in a world where most things can be rationally moved off Cobol and its happy gang of CICS, IMS, et al has already moved away, leaving a hard core (or as Micro Focus would call it, a “strong heart”) of tech that just works.
Or at least nearly. All code needs tweaking as the business logic evolves and if you have 100,000 programs (that’s programs, not lines of code) in Cobol, you’re going to add functionality in Cobol, which is of course how we got to 100K in the first place. The 100K programs (yeah, it scares me too), have captured a lot of business logic. They document how exactly the firm makes money (or in the case of insurance firms, the lies it tells to keep its money) far better than any pile of unread documents all large firms accumulate.
The problem with being reliable is that for years now this huge bulk of code hasn’t been improved, which is of course one of the reasons it has been reliable. Doing the un-sexy stuff in the back office, or more likely under the back office, means few people are familiar with the overall structure or have picked up “the way we do things around here” and to make it more fun, the demographics imply that about 14 per cent of them are expected to retire in the next five years.
IBM reckons there’s roughly a million Cobolers out there, so that’s 25,000 to 30,000 jobs needing filling just to keep us where we are. But as we all know merely knowing the language, it takes time to get to the position where your changes reliably do more good than harm, especially if all you have to go on is documentation written under duress 15 years ago by a guy who is now going to play golf until he dies and isn’t answering the phone.
What's cool about Cobol?
Part of the joy of journalism is hearing about really mad stuff, as occurred when IBM fellow Kevin Stoodley introduced me to the idea of Cobol for mobile phones. Forms-based apps on any platform work with little change to the massive beasts that book tickets, provides insurance quotes, etc, but gesture-based interfaces require that the top level mainframe code is refactored to be responsive to my ham-fisted gropings of a fondleslab.
This is already generating some useful paid employment for some of you. Fortunately IBM and Micro Focus have spent the necessary effort to ensure that Cobol can still access a good set of modern libraries, so you’re not restricted to ISAM, SNA, Embedded SQL and CICS.
But last week at a F#unctional Londoners Meetup where the hip young programmers met to look at the Mbrace distributed processing framework something quite interesting happened.
I felt a bit old when they started talking about the need for better transaction controls, and didn’t embarrass my son who was there, (yeah, I’m old) by saying what they needed was CICS, but it did rather look that way.
CICS/Cobol has been the centre of mega-scale transaction processing for 40 years and it does it rather well, mostly not requiring the programmers to think all that hard, and if you’ve had to debug maliciously complex multithreaded code, even in a language like Java, you should be able to appreciate this quality. The number of transactions handled by CICS per second makes the combination of Facebook, Twitter and LinkedIn look like the traffic for CreationistsWhoCanActuallyThink.com.
Part of the image problem for Cobol is the way we remember the development environments, based upon green screens and the gruesome 3270 terminal whose default reaction to almost any stimulus was to lock the keyboard. These days Cobol has (at last) caught up with what we have come to expect for Java and C++, so you get to use Eclipse and Visual Studio, albeit having to type faster to cope with the bulky syntax.
It probably doesn’t shock you to learn that few universities teach Cobol. On my degree it was treated rather like a 1950s information film about venereal disease and some barely even mention it. IBM runs competitions like “Master the Mainframe” to try to get bright young things into the game, but it’s hard work pushing uphill against the trendy languages.
There are apparently hundreds of universities who give at least some skim and people say good things about Marist College, but supply vs demand does seem to be drifting in favour of developers – even if Cobol ultimately does have more yesterdays than tomorrows. ®
Dominic Connor worked on getting Cobol to work properly under OS/2, which was so successful that he’s now a City headhunter.