Every few years an alarm goes up about the shortage of COBOL programmers, and then it dies down. While it’s hard to tell whether this cycle occurs because programmers are found or because other solutions are identified, the latest resurgence of interest is at least in part due to the pandemic and state governments’ use of software for social services that couldn’t stand the increased caseload of tens of millions of unemployment claims.
As we continue to sit in the midst of the pandemic, organizations are thinking about the many ways businesses will have to change. For instance, will cash still be used in five years or will the business need to support some kind of cryptocurrency? It’s time to ask those big questions now—and determine whether it’s possible to make changes without touching COBOL code.
For most organizations, I believe that in answering these questions they’ll find that it’s time to start migrating away from COBOL.
The Rise (and Fall) of COBOL
COBOL is one of the earliest programming languages. It was invented in 1960 and rose to prominence as a language that required minimal programming skills. Part of COBOL’s initial attraction was that it was a domain-specific language designed for business—not only was it easy for programmers to learn, it also could be understood by executives; hence, the acronym for “Common Business-Oriented Language.”
COBOL was also one of the few programming languages that understood the requirements of business computing—most simply, the fact that an amount like 10 cents can’t be represented accurately in binary was a huge challenge. If you’re a bank, small rounding errors on each transaction add up. Libraries for business arithmetic could be written in other languages, but they’re scarce and hard to find.
While COBOL never disappeared, its influence faded in the 1980s but many large institutions failed to transition away from it. Today, there are billions of lines of code in governments, banks, enterprises and elsewhere performing essential business functions with few programmers able to maintain them.
Part of the reason why COBOL fell out of fashion was its inability to adopt things such as modularity or breaking down problems into smaller, functional pieces. When COBOL was invented, old business software was monolithic—and monolithic in a very deep sense. Internally, the software wasn’t partitioned into separate components that could be updated without affecting each other. It also tended to model forms that humans would fill out and couldn’t be submitted until the form was complete. Putting a web interface in front of those monoliths leads to a predictable result: long, complex forms that can take hours to fill out and are close to unusable on the modern web.
While the COBOL language itself has evolved over the years (with revisions released in 1961, 1974 and 1985 and object-oriented COBOL released in 2002), you still have to ask: what will it take to bring a COBOL program written in the 1970s or 1980s up to date? Is redesigning a program to take advantage of COBOL 2014 any easier than porting it to Java or Python or Go or Rust? Furthermore, COBOL looks unfamiliar and forbidding to most modern programmers, which likely caused it to lose popularity in the first place.
Finding an Alternative
So, where are we now, with our billions of lines of COBOL running the world’s governments and finances? We certainly need more people who know and understand COBOL programs. There’s a lot of old code that needs to be maintained, pure and simple.
But it goes deeper than that. COBOL is just another programming language; if we’re going to maintain (or replace) that software, we need programmers who understand the engineering decisions that made the software what it is. Programmers used a lot of tricks to work around the limitations of 1960s computers. Those tricks just don’t make sense to modern programmers; they solve problems we no longer have. We also need engineers and managers who are willing to look at our current situation—for example, the huge surge in unemployment applications—and think beyond the short-term solution. What does it take to reinvent current systems rather than replacing them? How can these systems become more human-centric? Can they be redesigned to match the way we live and work now? Putting a web front-end on a monolithic business process from the 1950s is the road to failure.
The new generation of programmers must understand financial programming and how to design business systems. There’s little value in migrating from COBOL if you don’t get something better in return. What you should get in return is the flexibility to add new features and new user interfaces, the ability to adapt to changes in competitive conditions and implement changes in the regulatory environment, and so on. We don’t yet know what those new features will be (perhaps cryptocurrency or virtual reality user interfaces), but we do know that businesses will need the flexibility to add them.
Simply put: Scrambling for COBOL programmers whenever there’s a crisis is not a viable business decision. Transitioning from COBOL is a change businesses will have to make eventually. This transition should be made when businesses have time to think it through, time to hire the right people and time to do a good job—rather than waiting for the next crisis.
In the meantime, while businesses are baking in the time to think through their transition strategically, it’s important to note that this isn’t an all or nothing decision—i.e. let’s scrap our legacy software and replace it by Jan. 1, 2021. This is not Y2K. Using a microservices approach offers numerous advantage. For one, businesses can split their existing infrastructure into different independent services. They can start with pieces such as authentication, then move on to things such as billing and other services. Whatever businesses decide, they need an approach that’s modular so that it’s easy to add new features as needed. That requires careful thinking about design—and that thinking is more important than the programming language itself.
