When software doesn’t evolve or move forward it is considered to be suffering from a curious ailment known as software entropy, or code rot. As the name suggests code rot is the slow deterioration of an application due to the lack of updates or advancements. It’s a phenomenon that exists in many organisations, but is most rampant in banks, airlines and insurance companies, the type of companies, ironically, that claim to be on the cutting edge. Don’t be fooled. At this very moment transactions worth billions of dollars are being processed on antique applications that were written in the days before man walked on the moon. But in a world where technology is moving at breakneck speed, how did this happen? The answer to this question lies in the past and is a curious mix of laziness, bad practices, and lack of vision.
In the 60s and 70s programming was a very different occupation than today. It required not only mental agility but physical agility too. Leading languages of the time only accepted instructions typed on to punch cards that were then manually fed to the computer. Depending on the complexity of the program there could be anything from 500 to over 1000 cards. This required programmers to lug heavy boxes from one terminal to the next whenever they needed the machine to perform a particular function.
Another annoying quirk was these cards had to be inserted into the terminals in a particular sequence or nothing would happen. This nugget of knowledge was especially useful for the office jokers who liked to give the cards a quick shuffle whenever the programmers weren’t looking.
This likely sounds like a nightmare to the modern user or developer. The phrase “more trouble than it’s worth” springs to mind. But these terminals had advantages. They were particularly efficient at retrieving information and performing complicated calculations and could perform these tasks much faster than humans.
While plenty of businesses were calling out for such functionality, it was the banks, airlines and insurance institutions that had the cash to adapt this new technology. This resulted in companies like J. P Morgan and Bank of America scooping up as many programmers and technicians they could find to implement custom programs to improve the productivity of their business.
Thankfully, Over the next few years programming evolved and became much less cumbersome. Advancements in storage and memory now allowed source code to be executed on disk rather than lugged around in heavy boxes. This breakthrough was gladly received by programmers and their strained backs. But the situation was still a long way from being perfect.
COBOL, the most popular computer language of this time, was known to be sturdy and reliable but also needlessly verbose (especially compared to today’s standards). Simple programs like adding two numbers together could take 15 to 20 lines. This might not sound like a big deal, however, for complex applications code could run on for a million lines or more.
Partially due to their size, but also due to the lack of decent software practices, testing and maintaining these types of applications were difficult and tedious. At that time, the emphasis was on getting the job done quickly rather than writing beautiful, well-structured code. This behaviour gave rise to sloppy and inefficient written procedures and subroutines. Multiply these bad habits over 10 or more years and the application begins to resemble a jungle of impenetrable code. A dark and dangerous place that can only be navigated by a certain group of people familiar with the terrain.
All these factors likely impacted on any decision about migrating these dinosaur applications to modern platforms. While everyone agreed something needed to be done, serious questions remained regarding the cost and the hassle any actions would bring. Programmers didn’t relish the idea of rewriting a codebase of such magnitude, and management certainly didn’t relish the idea of writing massive checks for the IT department. As always, the result was to kick the can further down the road and hope money and resources would present themselves in the future. This type of wishful thinking continued for the best part of 30 years. In the meantime, the world moved on: the computer age became the internet age, then the internet age became the mobile age. Unfortunately, no magical money tree sprouted to save the day, and nothing ever changed.
This scenario wasn’t unique. It was replicated in thousands of businesses across the globe. High profile companies like United Airlines, J. P Morgan, even the Pentagon, to this day still have legacy COBOL systems controlling large parts of their operations. These applications still chug along on old relic mainframes, but they are not updated, merely maintained. Down through the years all attempts to upgrade have all ended in failure.
Now, the original developers, the founding fathers if you will, have long retired, taking with them years of knowledge and experience. This has dampened hopes of meaningful migrations ever taking place. Their replacements, new age developers schooled in modern languages of Java and C++, aren’t much help. They look upon the ancient syntax of COBOL like tourists staring at hieroglyphics on a wall in Egypt. The best they can do is conceal the problem from the outside world. They do this by creating fancy web and mobile phone frontends to mask the festering applications beneath. No doubt there are still regular meeting about attempting another update, the result likely being to kick the can a little further down the road. Next year or maybe the year after something will be finally done to eliminate the rot.