5 ms·

Which is a bad attitude in general, but an especially bad one for an industry known to use exceedingly old tech. In all honesty: why is COBOL so prevalent in t

Which is a bad attitude in general, but an especially bad one for an industry known to use exceedingly old tech. In all honesty: why is COBOL so prevalent in the finance sector? It can't seriously be SO GOOD as to be completely un-replacable?

Rubikan 8y ago
> In all honesty: why is COBOL so prevalent in the finance sector? It can't seriously be SO GOOD as to be completely un-replacable? It is not un-replacable in itself, I'd imagine it is just a huge undertaking and many higher ups are afraid to do it and risk something going wrong.
bauerd 8y ago
No one who's in a position to decide about COBOL's replacement has any strong incentives to do so. You don't want to be the one exec who made that risky move and crushed half their bank's tech foundation in the process.
theandrewbailey 8y ago
"If it's not broken, don't fix it" is a saying for a reason. This might be it.
Marazan 8y ago
It's not the language, it is the system that was built. You can't just throw it away.
yxhuvud 8y ago
Banks were among the first to computerize their systems, and switching systems cost a lot of money, regardless of industry. Hence they have a lot of old systems.
mcv 8y ago
It's not unreplaceable, but it costs money to replace, and it's a risk to replace it; the old system is tried and tested, whereas the replacement might not work quite the same way. So at any specific time, the safer and cheaper option is to stick with the old system, despite the growing risks and costs in the long run.
gaius 8y ago
why is COBOL so prevalent in the finance sector? It can't seriously be SO GOOD as to be completely un-replacable? To use hip modern buzzwords, it’s a DSL. In addition, it runs on hardware specifically designed around its idioms.
blihp 8y ago
Replace COBOL with Visual Basic, Java, Javascript and you have your answer. It's what was used when those finance applications were written and became part of the technical debt of the institutions that wrote them. Your shiny new language/framework today may one day be fondly remember by future generations as 'why are we still using this crap?'
pjmlp 8y ago
It applies to any old project. Imagine that you need to replace a live system, downtimes are not allowed, probably provide a new UI while offering 100% of existing features. There is no documentation available, or even if there is one, you won't find anyone in the building that will put their hand on the fire for how much of it actually maps to the running application. So a project of reverse engineering existing application into a requirements document or updating the existing documentation usually takes several months. Now just for a very basic project cost, consider the monthly salary of everyone involved, multipled by the amount of months. And we are just speaking of phase I, then there is the actual re-write, followed by verification that 100% of the old features are still present on the new system. Naturally it is cheaper to keep existing systems running. This applies to any old platform, not only COBOL systems.
- FussyZeus 8y ago
  Except for the detail that COBOL programmers are outrageously hard to find, thusly expensive, and are only continuing to get harder to find and more expensive.
  - pjmlp 8y ago
    Except that it still cheaper to pay a pile of bucks to IBM and Unisys to keep those systems running than re-write them. Which by itself shows how much money such re-write would eventually cost.
- __sr__ 8y ago
  And in some cases, the source code is lost.
__sr__ 8y ago
Because financial sector is run be people who consider engineers a liability[1]. Instead of evolving with time in 80s and 90s as the world moved to modern systems, they clung to their increasingly legacy systems. After all, why would an MBA toting executive from a big bank bother with something as menial as technology? At financial sector firms, Engineers are not meant to be seen or heard. Try proposing a new idea — or a move to a newer system — you’ll be shot down faster than you can say technology — by the same people who have led us from one financial crisis to another in their infinite wisdom. Most big banks have a bunch of security people whose sole job is to make people’s life hell by spreading as much FUD as possible[2] — that’s what keeps their jobs secure, after all. And they are the only “engineers” who are heard. They make sure that anything new is not adopted till the rest of the world has already started abandoning it. The primary focus in the technology departments of big banks is to maintain the status quo. New development is rare. New ideas are crushed before they can see the light of the day. As a result, good engineers leave as son as they can and the only ones left behind are the ones who are content living a life of mediocrity — maintaining the status quo. [1] I know someone who was told something along those lines when they joined a big financial institution as an engineering manager. And not all financial companies work that way. Those who embraced technology reaped the benefits and continue to do so. [2] I am not suggesting that security is not important. But security people at these institutions take it to a whole different level — to the point where things that should not take more thane a few days end up taking months — if they allow it, that is. Funny how all their objections vanish when someone from upper management asks for the same thing.
justaguyhere 8y ago
One of my jobs was for a subsidiary of a European plane maker. Some of their critical systems were written in Fortran 77 and was decades old in some cases. I have no clue about F77 or aircraft engineering, but my team was told repeatedly that these software ran flawlessly and nobody was ever to touch it (we made some fancy JAVA UI and called F77 executables in the background). I guess a time will come to sunset, but just not yet. As above, may be these COBOL systems have been battle tested for a long time and they are good. Other reasons could be, "if it ain't broke then why fix it?" or that there aren't enough people to act as a bridge between the old and new systems so it is hard to do such projects (as other comments have pointed out)

Rubikan 8y ago

> In all honesty: why is COBOL so prevalent in the finance sector? It can't seriously be SO GOOD as to be completely un-replacable? It is not un-replacable in itself, I'd imagine it is just a huge undertaking and many higher ups are afraid to do it and risk something going wrong.

bauerd 8y ago

No one who's in a position to decide about COBOL's replacement has any strong incentives to do so. You don't want to be the one exec who made that risky move and crushed half their bank's tech foundation in the process.

theandrewbailey 8y ago

"If it's not broken, don't fix it" is a saying for a reason. This might be it.

Marazan 8y ago

It's not the language, it is the system that was built. You can't just throw it away.

yxhuvud 8y ago

Banks were among the first to computerize their systems, and switching systems cost a lot of money, regardless of industry. Hence they have a lot of old systems.

mcv 8y ago

It's not unreplaceable, but it costs money to replace, and it's a risk to replace it; the old system is tried and tested, whereas the replacement might not work quite the same way. So at any specific time, the safer and cheaper option is to stick with the old system, despite the growing risks and costs in the long run.

gaius 8y ago

why is COBOL so prevalent in the finance sector? It can't seriously be SO GOOD as to be completely un-replacable? To use hip modern buzzwords, it’s a DSL. In addition, it runs on hardware specifically designed around its idioms.

blihp 8y ago

Replace COBOL with Visual Basic, Java, Javascript and you have your answer. It's what was used when those finance applications were written and became part of the technical debt of the institutions that wrote them. Your shiny new language/framework today may one day be fondly remember by future generations as 'why are we still using this crap?'

pjmlp 8y ago

It applies to any old project. Imagine that you need to replace a live system, downtimes are not allowed, probably provide a new UI while offering 100% of existing features. There is no documentation available, or even if there is one, you won't find anyone in the building that will put their hand on the fire for how much of it actually maps to the running application. So a project of reverse engineering existing application into a requirements document or updating the existing documentation usually takes several months. Now just for a very basic project cost, consider the monthly salary of everyone involved, multipled by the amount of months. And we are just speaking of phase I, then there is the actual re-write, followed by verification that 100% of the old features are still present on the new system. Naturally it is cheaper to keep existing systems running. This applies to any old platform, not only COBOL systems.

FussyZeus 8y ago
Except for the detail that COBOL programmers are outrageously hard to find, thusly expensive, and are only continuing to get harder to find and more expensive.
- pjmlp 8y ago
  Except that it still cheaper to pay a pile of bucks to IBM and Unisys to keep those systems running than re-write them. Which by itself shows how much money such re-write would eventually cost.
__sr__ 8y ago
And in some cases, the source code is lost.

__sr__ 8y ago

Because financial sector is run be people who consider engineers a liability[1]. Instead of evolving with time in 80s and 90s as the world moved to modern systems, they clung to their increasingly legacy systems. After all, why would an MBA toting executive from a big bank bother with something as menial as technology? At financial sector firms, Engineers are not meant to be seen or heard. Try proposing a new idea — or a move to a newer system — you’ll be shot down faster than you can say technology — by the same people who have led us from one financial crisis to another in their infinite wisdom. Most big banks have a bunch of security people whose sole job is to make people’s life hell by spreading as much FUD as possible[2] — that’s what keeps their jobs secure, after all. And they are the only “engineers” who are heard. They make sure that anything new is not adopted till the rest of the world has already started abandoning it. The primary focus in the technology departments of big banks is to maintain the status quo. New development is rare. New ideas are crushed before they can see the light of the day. As a result, good engineers leave as son as they can and the only ones left behind are the ones who are content living a life of mediocrity — maintaining the status quo. [1] I know someone who was told something along those lines when they joined a big financial institution as an engineering manager. And not all financial companies work that way. Those who embraced technology reaped the benefits and continue to do so. [2] I am not suggesting that security is not important. But security people at these institutions take it to a whole different level — to the point where things that should not take more thane a few days end up taking months — if they allow it, that is. Funny how all their objections vanish when someone from upper management asks for the same thing.

justaguyhere 8y ago

One of my jobs was for a subsidiary of a European plane maker. Some of their critical systems were written in Fortran 77 and was decades old in some cases. I have no clue about F77 or aircraft engineering, but my team was told repeatedly that these software ran flawlessly and nobody was ever to touch it (we made some fancy JAVA UI and called F77 executables in the background). I guess a time will come to sunset, but just not yet. As above, may be these COBOL systems have been battle tested for a long time and they are good. Other reasons could be, "if it ain't broke then why fix it?" or that there aren't enough people to act as a bridge between the old and new systems so it is hard to do such projects (as other comments have pointed out)