by John Browne, on Oct 2, 2020 1:16:27 PM
One of my colleagues just told me about a conversation he had with a major financial institution.
Would it shock you to learn that VB6 is still running in some of the biggest banks and insurance companies? I am, as they say, disappointed but not surprised.
I remember getting a replacement debit card at a Bank of America branch a few years ago, long long long after Windows XP was well out of vendor support. When it came time for me to set up a PIN for the card, the bank person turns the monitor to face me so I can type in a PIN in private.
And there, right in my face, is the Windows XP logo on the desktop.
Bank of freaking America.
I don't know if BofA has a side of VB6 to go with their XP entree, but again it wouldn't surprise me.
Financial services practically invented legacy
Although the modern computer was originally built to help kill people, it rapidly morphed into a tool for that other popular human pastime, counting money. As a matter of fact, my genesis in software was at a company that sold banking software; we created versions for IBM, Burroughs, and Honeywell mainframes (yeah, I'm dating myself here). Several tasks necessary in banking were crying out for automation from the days of Ebenezer Scrooge: processing checks, calculating interest, and creating statements. Computers made those operations way more efficient than armies of clerks with green eyeshades perched on stools with quill pens.
Maybe because finserve entities were deeply invested in mainframes they were quick to embrace client-server solutions when PCs became affordable, sufficiently usable, and acceptable. Mainframe apps are complex and expensive to write, and individual departmental IT requirements could go into a black hole of ever-slipping schedules, while a client-server app to solve the same problem might be actually attainable, particularly if one turned to external resources while the High Priests of IT focused on development schedules measured in years, not months.
We know it's a historical fact that when Visual Basic hit the streets, people in need of quick and dirty computing solutions gobbled it up. By the time the last version (6.0) shipped, it was the single most popular and widely-used programming platform in the world. It came as close to offering an "anybody can do this--plug and play" approach to application building as anything before or since. You could create a simple database on Microsoft Access or even SQL Server, then grab some third party component, hook it up to the database, attach some simple business logic and Bob's your uncle: you've got a useful application. Sure the code was crazy bad, uncommented, weakly typed, and used stupid variable names like "a" or "Suzy" but hey, it scratched an itch.
So it's not surprising that some of that legacy client-server code is still running in banks, insurance companies, credit agencies, and so forth. Few of those applications look like they did when they were new (to be honest, neither do I); instead they have grown into vast, sprawling, disordered, complex messes that provide critical functions and can't be discarded.
Which brings us full circle to the point that the Big Banks have actual VB6 apps still in production? Long after it's been out of vendor support. Which means out of FDIC regulatory compliance for information systems and security. But more importantly, it's just a Bad Idea.
Anybody relying today on a mission-critical system written in VB6 is taking a lot of risk. Risk that the next Windows 10 update will kill the app. Risk that those apps were written in a way to allow for attacks like SQL injection or buffer overflow. Risk that you won't be able to hire experienced programmers for a dead language. Risk I'd prefer the keepers of my tiny store of lucre not take, thank you.
But all is not lost. You can modernize that VB6 code to run the same application but written in C# or VB.NET. You can even (gasp!) turn it into an actual web application.
And then you can turn your attention to those mainframe computers you still have.
