[cntlzw]

> “Logic doesn't deteriorate,” said Bob England, a COBOL developer and president of England Technical Services. “Until the business rules change, that code is as good as the day it was born.”

True, but the business context always changes. I doubt most of the payroll logic from 50 years ago is still in use today. Therefore someone needs to write new code, or change the old code.

> Many COBOL applications are large; rewriting them isn’t cost-effective—or even necessary.

Yes, your IBM sales rep makes sure of it.

[cutler]

I've never bought this one. Surely a rewrite in Java/Kotlin or C# would save you a fortune in the long run.

[thaeli]

The time horizon on that payback is very long and the risk of total project failure is very high.

[cutler]

What's the biggest bottleneck?

[mmcdermott]

Figuring out the requirements is a research project unto itself. The churn of people over the years means there is no single source of truth for what the system does or why. I wrote an answer about this at https://softwareengineering.stackexchange.com/questions/4252...

You generally want to improve on what you have in some way (or else why do it?), but the line between the warts and requirements is blurry.

Incremental replacement is often a hard sell on the relationship side of things because the customer is seeing a reduction in functionality until everything is done. You can mitigate it and work around it, but it tends to excite waterfall urges which drives up risk.

You also have the fact that the organization keeps changing, so your target is also changing.

There is also an opportunity cost to the whole venture. All that time you spent rebuilding what you had could have been put into new ventures or back into core business.

If you look into modernization type efforts, you see a lot of failure and a lot of loss. That isn't to say it's impossible or that it isn't ever the right answer, but it definitely isn't safe or easy.

[notsapiensatall]

Probably the average tenure of C/VP-level sponsors for such a project.

By the time the gains would be realized, the muck-a-muck will have moved on to a different company. They tend to think in quarters, not years.

[WorldMaker]

Also, sunk cost fallacy. Any reasonably complex COBOL application has lots of lines of code, which are easily counted and in some cases may have even been originally paid for per-line on expensive contracts still on file. That gives a lot of "weight" to that sunk cost on the books, even in timelines of half-centuries. "You want to rewrite a hundred thousand lines of once very expensive code?" you can hear the ghosts of bean counters past shouting in the corridors no matter how much you explain to them that they should have better amortized and depreciated those costs decades ago.

[tdeck]

Rewriting software is a massive slog and is prone to all kinds of subtle, possibly very expensive bugs. Especially when the original software has no tests to verify expected behavior in edge cases.

[kayodelycaon]

If you hired and trained competent people to do the rewrite, sure. A lot of places will just outsource to a cheap offshore team and be surprised when nothing works.

[mellavora]

> True, but the business context always changes.

What about the regulatory context?

I'm thinking of banks, for example.

[alex-nt]

Regulatory changes in banks kept accelerating in the last 50Y and I see no reason this will stop. It is harder and harder for them to keep up. Reasons for this are:

* Banks still have very old codebases and changing anything is fear inducing for everyone (automated testing is a new things for a lot of teams)

* Banks control very little of their core software. They have a lot of vendors for the same thing. You will see multiple vendors delivering basically the same thing in different parts of the bank, and at the same time multiple versions of those vendor applications in diferent parts of the bank. Integrating this is a nightmare (it can take more than 1Y to move a tag in a XML).

* IT is still mostly used for marketing purposes in banks, it's not a way of doing things. The design/integration is mostly discussed/designed by functional people. They are great, but it does happen that they don't see the full implications of their choices till it is too late. Also, because this is a design 'from above' changing anything takes a lot longer. For any change you have to convince a lot more people till you get to the actual person that will have to do it.

* A lot more complicated management reasons. Nobody wants to take a hit on a new IT project, and few people have the IT & banking knowledge to move such a project (why would you? they pay is average). You cannot progress with just one of them. Places where these projects happen is mostly close to pricing/trading as those are seen as profit centers and the bank is more willing to fail a few times till it can build something decent. As you get closer to the guts of the bank things get more and more...problematic.

Edit: I had to add this. Central banks are also bad at IT, they do not set an example worth following. I consider this the main reason why all our interactions with banks are less than ideal online.

[raverbashing]

> What about the regulatory context?

It's probably even worse