I understand that old programs are extremely stable, but I don't understand why they are relevant. The world changes so much, why are these programs still useful?
That's a very techie view (and I speak as, largely, one:)
Core accounting principles don't change so much. Core payroll principles don't change so much. Core finance principles don't change so much.
We have a technology-oriented view that "world changes so much", but there are domains where that's true, and domains where that's not true.
Several times in my life I had the luck to have a mentor ask me, when I propose some obvious technological change and improvement, "what's the business advantage? If I let you spend X amount of hours over Y days to accomplish technical change Z, in which way will the business be better?"
In the world of startups and ___-tech, technology stacks matters and change and it's a whirlwind world of frameworks and languages and webapps stuff.
But in the core, back-office, cost-centre business of the company... the rules are complicated and numerous but in a way stable enough that solid stable complex software from 30 years ago still has value.
The world changes little-by-little, not all at once.
Let's say your application (100k LoC of Cobol) handles payroll. Your government introduces some new rules about how paternity leave should be handled. You have two options, rewrite the 100K lines into Java and add the new rule, or just add the new rule in the Cobol app. The latter is cheaper, at least in the long term, so that's what you do. Now you have 101k lines of Cobol.
20 years, four tax reforms, three mergers, five international expansions and fifty lawsuits later, you have migrated 100k lines of Cobol to Java, but your app grew and is now 3 million lines.
I've worked at organisations which have mainframe applications that have been running for almost 50 years. One of the funnier reasons I've heard about why these '100k lines of COBOL' programs never get rewritten is that no one really knows the full extent of what they do, and even if they do know the full extent of what they do, no one really knows the full extent of why. The business requirements that these programs cover are long since lost, but the program still remains. Even if this isn't a 100% true anecdote, it's an amusing one.
It is a 100% true anecdote at any number of businesses. It's philosophically enlightening in a way and related to an increasingly profound adage of "Purpose of the system is what it does" (which can be applied to IT and political and social and school and other systems through various lenses).
There are any number of systems out there which are "self documenting" in a weirder sense that what they do is what the rules are, rather than other way around. There's no external document or business process ruleset that describes what they do at the level of detail and accuracy that code does. There are a myriad edge cases built in which are important and relevant and likely still true (until somebody actively decides to change some rules) but not well documented or understood. I'm working on a government payroll system and it is mind.boggingly more complex than ever I could have possibly imagined and it still blows my mind every day. We have tens of thousands of time & labour rules due to hundred unions making thousands of negotiations over decades, on top of complex baseline payroll and taxation rules across governments and provinces and levels.
Attempts to rewrite such a software almost always, almost inevitably, take much longer and cost much more not just because of technical and architectural challenges, but because of, well, hubris - assumption that just because we can migrate webserver code across platforms, we can migrate a payroll system across platforms as well. Turns out one is orders of magnitude more complex than the other, we are just not used to thinking that way :).
> We have tens of thousands of time & labour rules due to hundred unions making thousands of negotiations over decades, on top of complex baseline payroll and taxation rules across governments and provinces and levels.
Working in healthcare/insurance right now and I can tell it's a very similar tangle of rules about which insurance plan covers what. The mess that's US healthcare ties up at least a trillion dollars a year in servicing its complexities. While it pays my bills, it pains me that a country can self-inflict such penalties just to not have some sort of government provided universal healthcare system.
Heck, I've got code I wrote ten years ago and no idea why it was done that way except for a vague memory of a request that I implemented but was never really used.
One plausible way to rewrite such a program would be to make it more modular. It's already likely all those rules are separated in modules and it is (allegedly) possible to call routines in different languages from COBOL code. You can, then, start writing those rules in Java, Python, C, or Rust (there is a Rust for z/OS!).
OTOH, you now have a more complicated and, perhaps, more brittle business-critical application you need to tend to.
> It's already likely all those rules are separated in modules
Have you seen much COBOL code? I had some dealings with a public school budgeting and payroll system back in the 80's, and I can tell you, it was a complete mess, with each program in its own source file (except some COPYs for record layouts). Here's just a simple " example:
COBOL has statements divided into paragraphs, each with a paragraph name. You can have for example, PARA-A down through PARA-D, one after the other. You can say PERFORM PARA-A and it's somewhat like calling a function, where it executes the paragraph and then comes back. Or you can say PERFORM PARA-A THROUGH PARA-C, and that's like calling a function made up of those 3 paragraphs. Or you can fall into PARA-A, and it executes the paragraphs one after the other until a GOTO occurs.
Another completely annoying thing is looping: PERFORM PARA-A VARYING IX FROM 1 BY 1 UNTIL IX > 10 is a for loop. The thing is, the code you execute is somewhere else, maybe 10 pages away. Nowadays there are probably some fancy code editors to help with these kinds of issues, but "back in the day", they were annoying as hell, and how good of a COBOL programmer you were depended on the depth of your mental execution stack.
The main advantages I think COBOL had/has is:
- no memory allocations; you spelled it all out in the DATA DIVISION.
- no various sizes of integers, floats, etc. You spelled it out with PICTUREs, like S99V99 is a signed number with 2 digits to the right and left of the decimal point. That's what it was on every machine.
- no buffer overflows; if you have PIC X(25), the thing is 25 characters, period. You try to move a PIC X(30) to a PIC X(25), and it just chops off the last 5 bytes. You move a PIC X(10) to a PIC X(25) and it pads with spaces. Very simple rules.
Combined, these fairly unique features make COBOL extremely portable.
Yes and no. Really, developed world have very stable laws, this is one of pillars of power.
So, new companies, like Uber, Apple (appstore), Microsoft (when created XBox), etc, sure have to create new infrastructure from scratch, because their new vision is their concurrent advantage.
But, for old businesses, like financial, energy, some others, most important to use all measures to cut transaction costs, and they achieve this by reusing old information infrastructure (not only this, but this is important part of equation). Unfortunately for old big businesses, their business models created when only mainframes could withstand their scale (clouds with micro- become mature enough, I think in 1990s; mini's just not considered as replacement of big machines), so big companies have large heritage on mainframes.
I know few cases, when large company move their infrastructure to cloud, but as I know, they mostly prefer to remain with old but reliable mainframes if possible.
At end of my speech I could add, I myself could be considered hunter from micro-world, who hunt for people who wish to switch (to micro and clouds), so I really know how much it cost :)
But to be honest, I feel romantic feelings to mainframes, as they are important part of history, I think we should save them for future generations.
