I convert dinosaur DOS apps to modern Windows platforms and agree with this article about why COBOL will never die. Yes, legacy code is often a garbled rat’s nest of code that needs to be tweaked. And yes, the underlying system often stays quite a lot the same even after a conversion.
The apps I convert are generally written in Clipper. Visual FoxPro and xHarbour can handle Clipper’s DBF data files just fine. Plus, much of the data manipulation code stays the same or is easy to change. Anything else is a complete rewrite, and for mission-critical apps, that’s not really an option.
Instead, I use VFP or xHarbour to put a pretty Windows GUI over essentially the same underlying code. This is exactly what happens with COBOL now too. It can have a shiny new front end but in the background is procedural code written years ago. That’s why it will never die.
Banking is the purest Capitalistic business; it pretty much has to be. So when anything gets done the first time, it’s made from scratch with whatever parts they had at hand at the time, patched with duct tape and spit. Once it’s plugged in and you know what it does, you will get no second chance to build it better. It’s already become part of the system. Since the banking industry works against both negligence and fraud by having your name and ID# attached to everything you touch, nobody wants to be The Person Who Broke It, because when things break, billions of dollars disappear and all anybody cares about is who’s to blame.
So yes, theoretically, you could test out a new replacement part before going live”¦ except there is no test version of the whole big system, no comparable simulation of it, because all of it was built from scratch with whatever parts they had at hand at the time”¦ Field service contracts last for generations in this industry. Everything gets fixed with a hot patch of the first crufty solution that came to mind for whoever was stuck fixing it. Code review, ha ha, what’s that?