Before the term “information technology” existed to label the field, learning COBOL (Common Business Oriented Language) was the only sure way to ensure a lifelong career in IT. Developed in 1959 in part from a previous language design created by the legendary Grace Hopper, COBOL was an early example of an attempt at write-once, run-anywhere code at a time when it was more typical to write software using closely linked assembly language on a mainframe, the only kind of computer around. COBOL’s design allowed for describing business processes, like breaking down and accounting for financial transactions, while its syntax relied on verbose procedural programming that contained aspects of English. Sixty years later, you’d expect COBOL to be the stuff of looping narrative videos at computer-history museums (in fact, there’s part of a floor devoted to mainframes at Seattle’s Living Computers museum, where you can see the old giants in action); maybe you’d hear the name COBOL used in an introductory lecture on computer science to explain how far we’ve come, and chuckle. Instead, COBOL remains widely and actively used across the financial system, with no good plan for transitioning to modern codebases, nor for keeping a viable coder workforce active. That’s a problem, because while some schools still teach COBOL and many outsourcing firms train employees in it to meet their employers’ needs, it’s not enough. Someone has to maintain an estimated hundreds of billions of lines of COBOL that remain in use, with billions more being written each year for maintenance and new features. Companies involved in keeping COBOL-based systems working say that 95 percent of ATM transactions pass through COBOL programs, 80 percent of in-person transactions rely on them, and over 40 percent of banks still use COBOL as the foundation of their systems. “Our COBOL business is bigger than it has ever been,” said Chris Livesey, senior vice president and general manager at Micro Focus, a company that offers modern COBOL coding and development frameworks. The Bank of New York Mellon told Computerworld in 2012 that it had 112,500 COBOL programs representing 343 million lines of code in active use. (And, yes, they’re still hiring COBOL coders in 2018.) The U.S. Social Security Administration (SSA) noted in a 2014 report that it “currently has roughly 60 million lines of COBOL in production that support the agency’s high transaction volume and enable the agency to meet its regulatory, benefit, and reporting requirements.” Starting in 2012, the Commonwealth Bank of Australia spent a reported US$750 million and five years migrating its core software away from COBOL on a mainframe to a modern platform (it’s not clear how that effort ended). The language never died, though its early practitioners have faded away, and the generation of programmers who built systems towards the end of the predominant mainframe era in the 1970s and ‘80s are largely near or past retirement age. Micro Focus estimates that about 2 million people worldwide actively work with COBOL, although how many directly write or modify code is likely a small proportion. That number is expected to decline rapidly over the next decade. It’s a slow-moving crisis with no crackling deadline, like Y2K, to focus the minds of chief information officers. Some code has run effectively with relatively few changes for decades, making it hard to come up with a convincing return on the investment required to transition to something more modern. So many companies have used COBOL reliably for high-volume transaction processing for so long—starting long before microcomputer-driven database servers could even begin to keep up—that the cost of moving to newer languages and hardware has simply outweighed the benefits. As the SSA’s then-CIO, Rob Klopp, said at a conference in 2016, “I’m pretty much of the opinion that what we need to do is understand the business rules and the business process that’s embedded in these legacy systems and just rewrite.” He also noted that billions of dollars would likely be needed to implement this kind of migration across multiple agencies. Though that money was never allocated, the recently passed omnibus spending bill includes over $2 billion for IT modernization, but mixes in maintenance funds. It’s clearly inadequate. Still, transitions must happen. “The legacy applications are not really sufficient to support modern business requirements,” said Dale Vecchio, the chief marketing officer at LzLabs, which makes “software-defined mainframes.” Vecchio started his work life as a mainframe application developer and spent roughly 20 years at Gartner managing strategy for application modernization before joining LzLabs in 2017. “You can’t just rewrite the whole thing,” he said—but you can’t leave it in place, either. Livesey of Micro Focus noted that the best you could hope for is spending millions and millions of dollars fraught with risk to get back what you got: “The best case is back to square one.” The crunch is coming, and it could sink businesses unprepared to deal with a lack of programmers.

Old code knew best The oldest computer program still running is arguably the Department of Defense’s Mechanization of Contract Administration Services (MOCAS), which manages over a trillion dollars across hundreds of thousands of contracts. It’s written in COBOL, though because it was launched in 1958, it was likely first written in a similar predecessor language, Hopper’s FLOW-MATIC. MOCAS has been updated routinely over the past 60 years and moved to ever-faster hardware, but it’s still the same at its core, consisting of about 2 million lines of code. Proposals to update it are floated routinely, but it’s still ticking away. (Not quite as old? The IRS’s main taxpayer data system from around 1960, written in assembly code.) In a modern version of COBOL, an archetypal “Hello, world!” program looks something like this (although back in the 1960s, it would have been somewhat more verbose): IDENTIFICATION DIVISION . PROGRAM-ID . HELLO-WORLD. PROCEDURE DIVISION . DISPLAY 'Hello, world!' . STOP RUN . The language ostensibly self-documents, because it’s so verbose and requires so many explicit declarations about what it’s doing. That’s an optimistic statement about any language. But its design was tailored to meet business needs. A series of operations in a company back office—like selecting, sorting, and summarizing the contents of a series of index or punch cards—could be replicated as an algorithm in COBOL. However clunky it might seem, the approach wasn’t to reevaluate how the operations were performed, but to transform them into code. “When I started in the early 1960s, we went into an organization and most of the people there didn’t even know what a computer was,” said Bill Hinshaw, the founder and CEO of COBOL Cowboys, a consulting firm made up of folks like him who spent their lives in the mainframe mines and who can now earn hefty consulting fees for coming back to help. “You had to extract from the organization their business rules and requirements. You had to learn how to write the code in COBOL while learning what their business was.” Micro Focus’s Livesey said, “These applications are so incredibly complex and sophisticated, because they encapsulate decades of business process and know-how.” As a result, many companies don’t know exactly how their systems run, because those rules extracted long ago are embedded in hundreds of thousands to tens of millions of lines of COBOL. Those 112,500 programs that the Bank of New York Mellon relies on? Most are tiny modules that carry out routine, easily duplicable tasks, like creating specific reports. But the interaction and batch processing carried out among them, coupled with the inevitable bugs and workarounds in language implementation and expression, mean that reproducing the system would take more than just feeding it into a COBOL to C# or Java converter. COBOL also suffers from the flaws of early computer languages, such as allowing arbitrary jumps via GO TO. While it allowed for procedures, parameters couldn’t be passed, and all variables could be globally modified anywhere in the code. This makes it extremely difficult to predict how any segments of code work in isolation, because you never know whether or not variables that seem to have a local context are being modified elsewhere by intent or error. That in turn makes it almost impossible to have a gestalt view of an entire system. Replacing any piece of code could have completely unpredictable effects on parts not even known to interact with it. (Later revisions of COBOL made it more modern, including adding object-oriented support, but very little COBOL is written in that. And there are hundreds of other variations of COBOL from the past 60 years.) An article in the 1978 issue of the Journal of Systems Management, “Flow in Structured COBOL Programs,” advocating for the use of structured programming standards described the benefits as avoiding “‘rats-nest’ or ‘spaghetti-like’ programs.” And a classic 1994 Dilbert comic strip featured Dilbert and Wally talking to a one-shot character, Irv: Dilbert: “I’ve never seen you do any real work around here, Irv. How do you get away with it?”

Irv: “I wrote the code for our accounting system back in the mid-eighties. It’s a million lines of undocumented spaghetti logic.”

Dilbert: “It’s the Holy Grail of technology!” While that’s a cynical view of programmers keeping themselves employed, Dilbert creator Scott Adams worked at Pacific Bell and knew the mainframe culture. But more telling is that the strip ran 24 years ago: “Irv” is long retired, but may have been hired back at several times his previous salaried hourly wage to work on his spaghetti.