
Banks should let COBOL die - artsandsci
https://thenextweb.com/finance/2017/04/25/banks-should-let-ancient-programming-language-cobol-die/
======
shepardrtc
The idea that large corporations are simply going to move on from COBOL is out
of touch with reality. It really can't be overstated how deeply old COBOL
programs are embedded into these corporations. I worked for one that had been
using them since the language itself was created, and while they all could see
the writing on the wall, the money to do the change simply wasn't there. Not
only would they have to do a code change, they would also have to do a
hardware change because all of this is running on mainframes. Not only does
this cost a lot of money, but it would also take an enormous amount of time.
What mid-level manager is going to stick their neck out and push for this?
What exec is going to ignore the guaranteed transactions that a mainframe and
a decades-old COBOL program can offer simply to secure a solid future for
which they may not even be around for?

But as far as training people to handle COBOL, well, that's simple. Look at
vocational schools of years past. Why can't you train a random person just how
to do COBOL? They don't need to do object-oriented programming or UX theory.
They just need to maintain and occasionally update some ancient program that's
been rock-solid for longer than they've been alive. It doesn't take a genius,
it just takes very specific training. And there are a lot of people that would
jump at a chance for some high-paying, steady job that they just need to train
for a year or so at night school.

~~~
scrollaway
Realistically, if, say, one of these big corps/banks with deeply-integrated
COBOL systems spent a few years revamping their systems to something more
modern and usable today, how much would it cost?

Running mainframes isn't cheap. COBOL programmers aren't cheap. Not being able
to improve these systems / innovate with them can cost the business a lot of
time/money. And if we're talking COBOL, we're talking at least 25 year old
corps.

How long's the ROI on moving over? How expensive does the maintenance of
antiquated systems get? It's easy to say that they're rock-solid and never
need to be touched, but is that really true? For example, lot of banks today
have a lot of absurd UX, often because of absurd internals and I know a lot of
that usually is "the system is ancient and nobody really touches it anymore,
that's just what it is now".

~~~
marktangotango
> Realistically, if, say, one of these big corps/banks with deeply-integrated
> COBOL systems spent a few years revamping their systems to something more
> modern and usable today, how much would it cost?

Success isn't guaranteed, maybe as low as 50%. When you say 'few years' it
intimates you don't appreciate the scale of some these systems. In the end,
retiring legacy systems isn't a technical problem, it's a product owner,
product management, and business problem. The business owners have to make
concerted, multi year effort to document their process as implemented, define
the replacement, and manage it's (re)implementation. This never happens.

~~~
Chaebixi
> The business owners have to make concerted, multi year effort to document
> their process as implemented, define the replacement, and manage it's
> (re)implementation. This never happens.

I wouldn't say it _never happens_ , but it certainly takes a couple tries and
a lot of time and money.

My employer is _close_ to being off our mainframe(s), but it will probably
take at least another 10 years to get rid of the last little dependencies.
We've already spent about 15 years (with hundreds of developers) getting to
the point where all the major online and batch processes have been
reengineered and have very small mainframe dependencies. The mainframe
development teams are very small and mostly focused on decommissioning work.

But yeah, it's a massive undertaking. In our case, the business was motivated
to pay for it because mainframes just couldn't scale for our main use cases.

~~~
bigato
Any chances we could read more about this somewhere? Sounds very interesting.

~~~
Chaebixi
> Any chances we could read more about this somewhere? Sounds very
> interesting.

Very, very unlikely. The company doesn't even have technical writers anymore
for internal projects, let alone technical historians. And with the time it's
taken and normal staff turnover, I doubt that there's anyone who really could
write about the whole effort based on their own experiences.

Basically, it consisted of building of building a new central datastore for
our content (that was pretty mature by 2005, when I started). Then hundreds of
smaller projects to migrate this or that process to read from or update the
new datastore or keep it in-sync with the old one. There was also a lot of
opportunistic piggybacking of new feature work onto migration projects or
migration work into new feature work. However, I only have the view of a
regular developer.

------
marktangotango
I get tired of seeing these same sensationalist falsehoods propagated without
challenge. So I shall challenge.

>> We did a piece the other day about how learning the ancient programming
language COBOL could make you bank.

>> Which can only maintained by small group of veterans, that grows thinner
every day.

>>There are almost no new COBOL programmers available so as retirees start
passing away, then so does the maintenance for software written in the ancient
programming language.

This is false because there is in fact tons of COBOL talent around (in the
US). The waves of offshoring in the '00s left many thousands of unemployed
COBOL developers. I personally know of 100's in the local market. A prominent
financial services and BPO firm off shored mainframe development, and laid off
many 100's here. Most got out of software development all together. This
skills shortage simply doesn't exist.

~~~
samBergeron
>> The waves of offshoring in the '00s left many thousands of unemployed COBOL
developers

If you were a developer affected by stuff in the '00s, you're probably nearing
the end of your career (unless you'd just started) The problem here is the
lack of a NEW talent pool.

~~~
DanBC
Age 30 in 2000 is 47 today.

Is 47 really "near the end of your career"?

~~~
washadjeffmad
Nearer to the end than the beginning, perhaps.

I always get a chuckle when some hopeful naif writes like they're going to
retire at 50 and be done. Most everyone I know who's tried that "gets bored"
and goes back to work or starts consulting after a half year trying to find
their feet. Those are also the ones who when asked what happened tell you
they've got plenty of good years left and are now planning on retiring at 70.

47 is still building steam in my experience.

~~~
nickpsecurity
Our company has high turnover on the bottom. A steady percentage of new hires
are bored, retired people. :)

------
JackFr
As someone who has worked in a few investment banks, Perl is a SIGNIFICANTLY
larger problem than COBOL.

While verbose, COBOL enforced structure and discipline, and it is very
possible for code to be maintained by someone other than the author.

On the other hand in the 90's and early 2000's many critical pieces of
software were written in Perl. While it is quite suited as a scripting or glue
language, I've seen elaborate integrated systems written in cryptic,
unstructured and undisciplined Perl, often with proprietary extensions.

And no one learns Perl anymore.

There is no way to maintain these projects, and in at least two projects I've
seen, what should have been a straightforward change lead to a large scale
retire-and-replace project.

~~~
woliveirajr
Sometimes the "no one learns Perl anymore" just means that no one is willing
to pay a good money for some change that the company wants.

~~~
protomyth
Yep. I know Perl (5 not 6) really well and programmed in it for about 10
years. No one I've seen actually wants to hire for it. I'm fine with that
because it wasn't something I loved much like the Transact-SQL programming
(love Objective-C and looks like Swift will be more work not love).

~~~
collyw
Thats seems true. I have a Perl jobs group on Facebook, and the salaries are a
fair bit lower than for Django (which I currently do).

------
jcranmer
> Döderlein says that banks have three options when it comes to deciding how
> to deal with this emerging crisis.

Option 4, which is what banks are actually doing to the best of my knowledge,
is to train new hires on how to write COBOL.

~~~
stoshe
Glad to see someone else pointing this out.

The problem with these systems is that they are very old, and thus do not
benefit from many of the more modern developments in the field nor do many
quality developers learn the language.

The benefit with these systems, though, is that they are very old. With that
age comes completeness. They're battle hardened, thoroughly tested, and a
known quantity within the institutions that leverage them.

History is littered with companies that attempted to replace the core of their
business with one big project written with newer technology, only to fail
catastrophically.

During my first gig with a bank, I was appalled to see the ancient technology
in play at the heart of the bank's systems, and the retired developers coming
in part time on schedules they set for outrageous hourly rates to do
maintenance tasks on that system. Over time, though, I came to realize that
this was the most reliable and cost effective solution the bank had available.

The third option listed is what I see happening, but at a much slower pace
than the article suggests:

> Basically, Döderlein suggests making light-weight add-ons in more current
> programming languages that only rely on COBOL for the core feature of the
> old systems. However, the key thing is how the connection to the old system
> is made. > Gradually banks will be able to address each and every product
> need that they have with new platforms that will replace the overly
> complicated COBOL add-ons. This compartmentalizes the banks’ COBOL-problem
> and makes it cheaper to fix, as it won’t have to be done all at once.

It's a glacial pace, but it's being attempted. The heart of the old systems,
though, were still untouched last I had visibility into those inner workings.

~~~
osullivj
You're correct on all points in my experience. My previous contracting gig
involved writing Windows Server based code for a UK mortgage lender that
interfaced between the internet based Hometrack valuation service, and a
Fujitsu ICL clone mainframe running the core Cobol system for the lender. The
key point about that system is that it is the core ledger for all the mortgage
accounts, which add up to many billions. It's the golden record of all the
mortgage accounts and payments. Replacing it with a new buggy system based on
the latest tech could kill the business.

------
bpyne
The issue with rewriting to newer technologies is relearning - the hard way -
all the requirements encoded over 40-50 years. Decision-makers are rightly
afraid of the $100M mistake. As some posters here said already, organizations
have to slowly phase in newer technologies and phase out COBOL ones.

The track record of Big Bang rewrites is not a good one. A few years ago it
was either ACM's CACM or IEEE's Computer magazine that profiled several high-
profile failures. The financial and time cost overruns were spectacular.

Banking and Insurance are not the only industries using COBOL. If you're in
higher ed and your institution uses Banner, you've got COBOL. During every
upgrade, our Banner team has to license the latest and greatest COBOL compiler
set from (I believe) Micro Focus.

I have to wonder if a split in technology exists between commercial and
investment banking.

------
potato_mOWX2EVX
People who don't know COBOL, IBM Mainframe or the industry write these type of
articles.

You want to loose the hardware - there's a solution for that. You want to
create modern web services over - there's a solution for that. You want to
code in a modern IDE - there's a solution for that.

If the systems that use IBM Mainframe were using Amazon ECS or Azure... the
same people would write articles about the lack of reliability of core servers
like banking and airlines.

------
mattmanser
PR piece for Auka. A classic example of one of pg's submarines[1].

Auka CEO Döderlein, mentioned a mere 5 times, says there are only 3 options,
ignore the problem, big bang rewrite, or bolt on new pieces.

Don't panic! Just call Auka. They have your new piece.

There's no mention of the option we would all pick, a gradual migration, of
course.

[1][http://paulgraham.com/submarine.html](http://paulgraham.com/submarine.html)

~~~
jacquesm
Agreed.

And besides that, banks should do what they want to do. That COBOL software
they are running is hardly ever a problem, the problems are usually in the new
stuff which has been far less battle tested and is connected to a hostile
network.

~~~
Bluestrike2
Legacy COBOL systems (hell, a lot of legacy code in general) is a perfect
example of the "if it's not broken, don't fix it" mantra. There's an
incredible amount of work involved in rewriting legacy code, and when you're
talking about doing so in a constantly updating, critical context like
financial transactions, it kind of highlights the need to take things slow and
carefully. My experience with old legacy systems (20+ year old C in
particular) is limited, but it was enough to recognize that just ripping it
all out is an awfully ignorant approach compared to a gradual migration of
what needs to be replaced.

It's also an incredibly expensive one, especially since it's a recurring
situation. No matter how clean and clear you think your code is, or how
thoroughly you've commented everything, in a decade or two, someone is
probably going to be groaning about it being legacy code.

------
taylodl
COBOL has been "dying" since the late 70s. Since that time I have seen several
languages and platforms come and go. Where I work our core application driving
the business is written in COBOL. Estimates are between $500 million to $1
billion dollars to replace it due to the number of systems interacting with it
and all the business processes affected by it. For that kind of money the
business wants a technology they can hang their hat on for twenty to thirty
years. So what are you going to choose? What languages and platforms in
widespread use today are going to be around in twenty to thirty years? Here's
what I think it will be: C, C++, Java and COBOL Hmmm. COBOL is in that list.
So if I think COBOL will still be around in twenty to thirty years and the
system is working fine now then what reasons do I provide to the business for
spending $500 million to $1 billion for the upgrade? Yeah - I can't think of
any either that warrants that kind of expenditure. So COBOL remains.

------
samBergeron
It's not only banks, I took an internship at an insurance company a couple of
years ago that had their entire mainframe written in COBOL.

Not only do they have a hard time finding people to replace their retiring
veteran developers, but for smaller companies (like this one) that can't
afford to pay ridiculous salaries for a top notch COBOL dev, they have to
settle for mediocre aging developers that can write COBOL and are on the job
market.

These devs are getting paid good money to work on critical systems and aren't
skilled enough to properly maintain them. It would be so much cheaper for
these companies to pay better devs to do more recent tech. But it's hard for
them to get out of that loop. Makes me rethink where I have my money.

------
maxxxxx
I wonder what people will say in twenty years about our NodeJS, AWS,
microservices and JavaScript systems.

~~~
Tom4hawk
Nothing critical (banks, military, factories) runs on NodeJS/JavaScript/AWS so
probably nothing. Do you think a lot about some old BASIC Accounting Software?

There are probably only two languages which might face similar problem as
COBOL: C and Java. For now they are both actively maintained and used for new
projects - so we are fine for at least next 50 years.

~~~
openasocket
NodeJS and Javascript yes, but critical things absolutely run on AWS.

~~~
myrandomcomment
Running on AWS and doing it correctly so that one of the many regional outages
does not cause you an issue is really hard and is a software problem. On the
other hand using a system of tested proven code that runs on a system that is
redundant by design at the lowest level of component (a mainframe cluster)
where the software does not have to have knowledge of the redundancy is a bit
simpler.

I really think people miss this very important point. Redundancy is
transparent for 99.9999% of the software you run on the old big iron systems.
For something like a modern application on AWS you have to know, understand
and code for the infrastructure.

~~~
openasocket
We're talking about two different issues here. First is the
architecture/software of a mainframe system, with all of its redundancy and
scaling. Second is the issue of hosting and maintaining your own hardware. On
the first issue I'll admit I don't know enough about mainframes, perhaps they
provide redundancy transparently to the programmer, but I'm a bit skeptical.
Perhaps you simply think the redundancy is transparent because you understand
the mainframe infrastructure deeply and internalized it? The second issue I'll
push back on.

If you just want to host your servers on EC2, the SLA is 99.95% uptime. So
that's about 4 hours of downtime due to outage a year. Put your servers in a
multi-AZ autoscaling group and you're pretty solid. Bonus points for having
autoscaling groups in more than one region. If you don't want to use any of
the other services AWS provides, you can simply use them as a basic hosting
service and get pretty amazing uptime. I've never used an old mainframe
system, can you get greater uptime than that? Including hardware failures,
power outages, network outages?

~~~
myrandomcomment
There was one point in my life when I was working for a large mainframe
company ;) A bank wanted to move a system to a new site. The uptime on that
system was 11 years. Uptime on a mainframe system is pretty much considered
100%

4 hours downtime a year is just way to much for some systems.

Just have a google for "mainframe uptime".

Yes the software is abstracted from the HW redundancy. You can pull CPUs with
running code in systems and things keep working. Really - walk up and pull the
CPU out. No impact to running code.

Heck you can run your private cloud on one:

[https://www.fool.com/investing/general/2015/01/24/heres-
why-...](https://www.fool.com/investing/general/2015/01/24/heres-why-ibm-is-
still-building-mainframes.aspx)

------
dhimes
This old argument again? It seems like every 25 years somebody brings this
up....

~~~
lightedman
Every 25 years? COBOL's only been around for about 60. You make it sound as if
it were something we've had happen far more frequently.

------
neillyons
I quite like the fact that programs written decades ago are still in use. In
the web development world there is so much churn. Anything you write now will
have been rewritten a year later. It is quite disheartening.

I like this quote from
[https://teuxdeux.com/purpose](https://teuxdeux.com/purpose)

> On that note, why the heck does every app need to change all the time? Can’t
> something on the Web be more or less finished?

However I have no idea what COBOL is like to work with so I am probably being
unrealistic.

------
jecel
One of the design goals for COBOL was that non programmers should be able to
understand it with a little training. That would allow non technical managers
to have a bit more control over their projects than they would have with
Fortran, Algol or PL/1.

I don't know how well that worked out, but other than Hypercard all other
languages I am familiar with (and they are many) only make sense to those who
can program in them. So though Java is often considered to be the modern
COBOL, at least in this regard it isn't.

------
filereaper
There's a misconception that COBOL is dead, its not, there are developers and
new compilers being built for it. [1]

IBM isn't sitting around waiting for COBOL to die out, its working out hooks
between COBOL and Java and introducing new languages like NodeJS [2]

The problem isn't money, its risk. No CIO is willing to risk moving to a new
system, and that's the problem that needs to be attacked.

[1]
[https://www.ibm.com/developerworks/community/groups/communit...](https://www.ibm.com/developerworks/community/groups/community/BinaryOptimizer)

[2]
[https://developer.ibm.com/zsystems/documentation/java/worksh...](https://developer.ibm.com/zsystems/documentation/java/workshop/java-
and-cobol-interoperability-introduction/)

------
agentgt
I know very little of COBOL but I have often wondered if bank COBOL software
could be transpiled (a quick googling shows there are transpilers). That is
COBOL -> Some_Other_language and perhaps Some_Other_language -> COBOL.

Then in theory you could write unit tests in some language to test the real
COBOL and the transpiled COBOL.

~~~
nickpsecurity
This company has been doing it for quite a while with an amazing toolkit for
language work:

[http://www.semanticdesigns.com](http://www.semanticdesigns.com)

[http://semanticdesigns.com/Products/Services/LegacyMigration...](http://semanticdesigns.com/Products/Services/LegacyMigration.html?Home=COBOLTools)

They also have a proprietary, parallel language I'd like to see go FOSS:

[http://semanticdesigns.com/Products/Parlanse/index.html?Home...](http://semanticdesigns.com/Products/Parlanse/index.html?Home=ParlanseForDMS)

------
zcdziura
I work for a large brokerage company that has a deeply integrated system
written entirely in COBOL on the IBM mainframe. That sucker is going no where,
and for good reason: it's incredibly efficient for what it does. As a batch
processing system, the mainframe simply can't be beat. We deal with millions
of dollars worth of transactions every day that have to be correctly accounted
for and reconciled. In order to get the performance required to do all of
that, we stick to the mainframe.

However, I do see the appeal for building off of the COBOL foundation using
more modern languages. Writing a UI in COBOL on CICS is an absolute nightmare
to deal with and maintain (not to mention my firm's egregious install and
deployment process that is nothing but red tape and TPS reports). I'm working
on a project right now where we're migrating some of our reconciliation
screens to the web, where the UI communicates with a Java/Spring Boot server
that itself interacts directly to the database using DB2 Stored Procedures.

In this space, I see a need for moving away from COBOL. But for the batch
processing? Not a chance.

------
alnorth
Say I wanted to learn COBOL, has anyone got any resources they'd recommend?

~~~
jacquesm
Programming in COBOL is best learned by signing up as a trainee employee in a
company that has been using it for a long long time and that employs a bunch
of old programmers who will be _more_ than happy to teach you.

It's a quirky language, (omit a single '.' somewhere and you're in a for a
world of hurt) has its neat parts and in general will come across as limiting
once you have been exposed to other, more expressive languages. But that's
probably also the reason it is still around, think of it as JAVA but then
conceived in the gray past. The original intent was to make a programming
language that would allow managers to program. That didn't quite work out.

~~~
mercer
Hey, apologies for randomly hijacking a comment for this question, but over
the past years you've been popping up all over HN's comment section with (it
seems) a rather eclectic and broad mix of experience, knowledge, and
(possibly) talent. I'm almost starting to suspect you're multiple persons (but
not really).

Have you ever written about how this came to be? I find myself to be similarly
broad in interest/experience, but I'd judge myself much more
superficial/limited in this regard because of the breadth of it all. I'm
curious how you manage it all.

~~~
logfromblammo
You've never heard of Jacques Mattheij, inventor of the live webcam?

~~~
mercer
Nope, perhaps too young for that?

That said, the guy doesn't even have a Wikipedia page! So how should I know?

~~~
logfromblammo
By being old, obviously.

------
coldtea
I wonder what banks would do if it wasn't for those genius suggestions in the
article... /s

------
codingdave
The decisions to keep these systems around are not about technology -- they
are about risk. Every IT lead in every bank knows the options for updating the
systems. But they also have risk management concepts attached to their
decisions, and because we are talking about banks, there is no such thing as
small consequences. Banks are extremely risk-averse, so if the system is
working and changes bring risk, you don't do the change. Figure that by the
time there really is nobody left to maintain it, somebody else will have taken
on the risk, and new products will be available. So there is less risk in
waiting for those products than in taking on new development efforts yourself.

------
mcgrath_sh
I am probably the odd man out here, but I took two semesters of COBOL and
really enjoyed it. I have been trying to figure out how to get into COBOL
programming, but the job postings are few and far between and seem to want
more experience than I have. I honestly think I would be really happy
programming in COBOL day in and day out.

As an aside, I think part of the reason I like COBOL is because I am an above
average to very good academic writer. I enjoy writing papers and find it hard
to meet page minimums because brevity and clarity is important to me. These
characteristics (good, clean, to the point writing) seem to translate to COBOL
more than any other language that I have used.

------
sandGorgon
Has anyone ever been part of any kind of migration from Cobol to anything else
? What happens to underlying hardware - is it even possible to migrate from
mainframe to the cloud without a complete reengineering ?

~~~
candiodari
Nobody uses mainframes anymore (except banks). They have emulators however,
that emulate a mainframe on windows.

~~~
0x445442
Not true. I recently worked at a major auto parts retailer and all part
pricing and availability data was stored in mainframes.

Currently I work for a major insurance company which has multiple data centers
with many, many mainframes... Think ~60K square feet worth of mainframes per
data center.

Mainframes are pervasive and aren't going anywhere anytime soon.

------
doublethedee
Banks have no issues hiring ex-offshore contractors who have been doing the
work for years. These guys can maneuver themselves through mainframe
technologies and show their proficiency with quite ease.

~~~
HelloNurse
Banks also have no issues retraining their IT staff to learn COBOL and ascend
from the Mostly For Fun Open Systems department to the Really Important
Mainframe Systems department.

------
squozzer
Compared to COBOL, that IBM PC is a whippersnapper. An IBM 370 would have been
a better match.

[https://en.wikipedia.org/wiki/File:IBM_System_370-145_und_Ba...](https://en.wikipedia.org/wiki/File:IBM_System_370-145_und_Bandlaufwerke_2401.png)

My dad programmed in COBOL for the Army, and he retired in 1975. That's how
old COBOL is. Knowing my dad, he probably still has his manuals, though
finding them might prove an archaelogical exercise

------
norea-armozel
It's kind of heartening to see programming languages like COBOL, Fortran, and
Ada still are chugging along helping folks solve their problems. I think
instead of trying to replace the language how about we design modern hardware
and software to work around it? Isn't that where virtualization can help (I'm
assuming too much probably with this question considering how many programs of
that era are hardware specific)?

------
einrealist
There is another important problem: the hardware and software these production
COBOL applications runs on (mainframes) is a burden for vendors like IBM.
Unless these mainframe systems are replaced by commodity hardware and
software, banks will always have to fear EOLs or high prices to keep
development viable for vendors.

------
wonderwonder
It's not just banks, a good number of industries still run legacy COBOL
systems. Timeshare for one.

------
erikb
I think they actually do. But very slowly. Last time I checked the amount of
known COBOL solutions was already surprisingly small. It's mostly people who
don't know anything about COBOL and COBOL fans who still believe that COBOL is
that important.

------
sigzero
Maybe so, but that would be an immensely huge undertaking costing a lot of
$$$$. Good luck getting them to do that.

------
ravenstine
I don't know about anyone else, but one reason I wouldn't get into COBOL is I
wouldn't want to be that guy who thought he could learn an archaic language
but lost the banks millions because of programmer error. I suspect a lot of
people simply don't want the kind of responsibility that working with bank
mainframes entails, even if they know COBOL.

------
skocznymroczny
Rewrite it in Rust/Javascript

~~~
jacquesm
You're going to have a hard time selling that combination.

~~~
protomyth
Is there a proper decimal library for either language?

~~~
jacquesm
Meh, who cares about a few cents ;)

~~~
protomyth
I still remember tracing down an odd bug involving taxes and contract
calculations that resulted from a programmer I thankfully couldn't identify
using a single precision float to do calculations that involved unit of
measure conversions that then had calculations involving contract terms and
weights. The original unit stored was a decimal with 30 total digits and 10
decimal digits. When I finally found the part of the code where decimals
suddenly because floats, I was inclined to do violence given it was 3AM and I
was chasing a couple of hundred thousand pennies in various places. It was
deep in the middle of a stored procedure so the standard excuses don't apply.

I swear there are not enough classes about numbers.

~~~
jacquesm
> I swear there are not enough classes about numbers.

Yes. This is one thing that irks me about these fads in programming, they all
solve problems that have long ago been solved and then re-introduce all the
bugs that were already discovered, fixed and forgotten about ages ago. Old
software is a very nice repository of information about edge cases and real
world complexity.

A $0.75 accounting error turned out to be named "Markus Hess". Precision
matters. If it works good. If it works but you don't know why it works: bad.
If it works, but has a small problem and you don't know why: bad. If you run a
$1M budget and you're off by $0.75: bad. And so on. You really don't want to
store anything to do with money in floats.

~~~
protomyth
I remember a 'Survey of Programming Languages' class in college. Perhaps a
archeology of code class and things already done. You are right, I wonder how
much of Computer Science knowledge is locked away never to be seen. Perhaps a
tax credit for companies that donate their old source code to the Library of
Congress.

------
merb
wouldn't it be great to have something like COBOL-grpc and rewrite everything
in rust/scala/java/c# but not all at once, more like the simple things first?

I think that would probably be a good business.

------
mavhc
If I were a bank I'd start a new bank, in Not COBOL, and put all my new
customers on that. Then after 10 years offer to move people still at the old
to the new bank, to get new offers.

~~~
kristianc
How do you message to your existing customers that you're holding their life
savings on fragile 1970s tech?

Also, you'll still have to write wrappers for the old tech (iPhone apps which
access the COBOL core) in order to maintain feature parity with the other
banks.

~~~
coldtea
> _How do you message to your existing customers that you 're holding their
> life savings on fragile 1970s tech?_

You mean "battle tested for 40+ years, totally solid 1970s tech"?

If anything, it's any crap they'd write now that would be MORE fragile.

~~~
kristianc
You're thinking like an engineer.

You're right, of course, but the public is trained to trust the latest and
greatest.

If 'battle tested' was the most salient selling point we'd be on Series 60 or
QNX phones.

'We're putting new customers on the latest technology and keeping existing
ones on our old systems' is not going to be an easy thing to message to the
general public.

~~~
GFischer
_If 'battle tested' was the most salient selling point we'd be on Series 60 or
QNX phones._

Actually, there are more Series 40 and Symbian phones sold today than iPhones
- 350 million to 200 million (India / rest of Asia, Africa and Latin America
are the main buyers). Many people here still miss the old Nokias. Of course,
Android is the new Series 60.

[http://gadgets.ndtv.com/mobiles/news/nokia-
sold-35-million-f...](http://gadgets.ndtv.com/mobiles/news/nokia-
sold-35-million-feature-phones-in-2016-strategy-analytics-1663745)

[http://tech.firstpost.com/news-analysis/india-smartphone-
shi...](http://tech.firstpost.com/news-analysis/india-smartphone-shipments-to-
overtake-feature-phones-in-2016-cmr-295949.html)

------
jlebrech
if you think COBOL is bad you haven't seen RPG yet.

------
eggestad
If you read the article carefully you'll notice that most banks DO NOT
maintain their own software! They licence the software, and usually the job of
running the system, from a software house. The article is based on an
intervjue of the CEO of Auka. Auka is a software house for a peripheral piece
of banking software. (read, he's selling software licenses). Try to look at
this from the banks point of view.

My first job was in one of these software houses for banking and finance(B&F)
who made both core system and peripheral software.

A bunch of us programmers tried to make the same sell to one of the bankers we
had on staff. (You need bankers to do the job of products manager in this
business). He looked at us like we're morons, and asked a rather pointed
question: "OK, say we rewrite the whole software stack in C++ (this was 1998).
What NEW banking products can we make in C++ we CAN'T make in cobol?" Answers
is of course; None, zip, nada. Last time you changed bank, did you ask who's
banking system is being used and in what language it was written in ? I'm
guessing not.

So banks go to the software houses to license a core banking system, and they
care pretty much about only two things: 1) Is it solid (i.e bug free. Few
things evaporate trust in a bank faster than there being questions about the
banks ability to do basic math right). 2) price

There have been a few cases when a new core banking system have been written
from scratch, and most have been failures due to being too buggy when
launched. Word get out among the banks and the system is dead. All will wait
until it's proven, no one will be the first one out of the gate. The bug free
requirement is a show stopper from the getgo.

On to price. The development cost of such a system is in the neighborhood of
250 - 500 million USD. The only way to get that down is to strip down the
features to a much simple system. The other software houses are just going to
sell an existing cobol system, with disabled features to match yours, and
underbid you.

Bankers, unlike most CS majors, actually understand how to calculate cost of
investments! Say 500M USD development cost, a future value calculation will
yield that you'll need a return-on-investment (ROI) of 20-50M US EVERY YEAR
FROM HERE TO INFINITY to make the investment pay off. (That's PROFITS, not
revenue)

Core banking systems are so feature stable, and have been so thoroughly
debugged over DECADES, that there is very little maintenance to be done. I'd
expect that each of these systems have a staff of 10-20 programmers
maintaining them (and they spend a lot of time doing other things). How big a
staff of maintainer will you new banking system need after launch? Even if it
was zero and you assume you pay each maintenance programmer 250k USD, a staff
of 20 still only cost 5M USD.

The article have a section "what can the banks do" left out a fourth option.
Instead of using CS majors to code cobol, you use B&F majors, and give them a
1-2 year education on doing cobol programming. The CS majors need 1-2 years of
on the job experience to reach a B&F Bachelor level understanding of what a
core banking system need to do anyway. Cost is the same.

One last point, say you do write a new system today your choice of language
will be either Java or C#. As database there is no viable alternative to SQL.
In 30 years no fresh CS major will touch Java or C# with a ten foot pole, and
you'll have to do another rewrite to the tune of 100-200M USD (assuming that
programming will require less hands).

Much cheaper to keep on educating non CS majors to do cobol.

------
dbg31415
And we should all switch to Metric, give up fast foods, and call our mothers
once a week... but look, it's never that simple because all of these things
take effort.

