Comment by jacquesm | Hacker News Reader

Comment by jacquesm | Hacker News Reader

Parent Full thread

COBOL is pretty easy to learn. The problem is that it is so full of archaic nonsense (less so with the more recent versions) that you will be tearing your hair out and wishing for something more modern.

COBOL's main value is in maintaining a pile of legacy codebases, mostly in fintech and insurance that are so large and so old that rewriting them is an absolute no-go. These attempts at cross compiling are a way to get off the old toolchain but they - in my opinion - don't really solve the problem, instead they add another layer of indirection (code generation). But at least you'll be able to run your mangled output on the JVM for whatever advantage that gives you.

With some luck you'll be running a hypervisor that manages a bunch of containers that run multiple JVM instances each that run Java that was generated from some COBOL spaghetti that nobody fully understands. If that stops working I hope I will be far, far away from the team that has to figure out what causes the issue.

It is possible that someone somewhere is doing greenfield COBOL development but I would seriously question their motivations.

> that rewriting them is an absolute no-go

Rewriting and expecting 100% feature-parity (and bug-parity, since any bugs/inconsistencies are most likely relied upon by now) is realistically impossible.

However, new banking/insurance startups proved you can build this stuff from scratch using modern tooling, so the migration path would be to create your own "competitor" and then move your customers onto it.

The problem I see is that companies that still run these legacy systems also have a legacy culture fundamentally incompatible with what's needed to build and retain a competent engineering team. Hell, there's probably also a lot of deadweight whose jobs are to make up for the shortcomings of the legacy system and who'd have every incentive to sabotage the migration/rebuild project.

That happens, but what also happens is that everybody is painfully aware of the situation and they do the best they can. Just like you or I would.

And of course, if you start a bank today you'd do the whole cycle all over again, shiny new tech, that in a decade or two is legacy that nobody dares to touch. Because stuff like this is usually industry wide: risk adversity translates into tech debt in the long term.

I suspect that the only thing that will cure this is for technology to stop being such a moving target. Once we reach that level we can maybe finally call it engineering, accept some responsibility (and liability) and professionalize. Until then this is how it will be.

Why would software technology ever stop moving? To a first approximation it is unconstrained by physical reality (unlike other engineering disciplines) so I expect it will keep moving at roughly the same rate. Maybe even accelerate in some areas.

Individual organizations can consciously choose to slow down. Which works for a while in terms of boosting quality and productivity. But over the long run they inevitably fall behind and an upstart competitor with a new business model enabled by new software technology eventually eats their lunch.

Software technology moves when we figure out new ways of doing software that bring some kind of advantage. If no one is finding new ways to do software that have any purpose, technology will stop moving. Physical reality doesn't really have anything to do with it - we're limited by human ingenuity, and possibly by the mathematical space of algorithms (though that's likely to be much larger).

For an example of this happening in a field, look at the glacial pace of advancement in theoretical physics for the last few decades, compared to 1900s. Or at the pace of development in physics in general in the centuries before.

Software trends seems to repeat themselves as we forget the lessons learned a decade ago. It’s more like fashion, in that sense.

> if you start a bank today you'd do the whole cycle all over again

It is worth noting that we now have much better processes and tooling than software developers had in the 60s. Some Cobol systems predate the invention of SQL or database normalization (3NF, BCNF, etc). Never mind the prevalence of unit testing and integration testing, automating those tests in CI, the idea of code coverage and the tooling to measure it, etc. Programming languages have also come a long way, in terms of allowing enforceable separation of concerns within a codebase, testability, refactorability, etc.

Sure, you can still write yourself into a codebase nobody wants to touch. Especially in languages that aren't as good in some of the things I listed (say PHP, Python or JS). But it's now much easier to write codebases that can evolve, or can have parts swapped out for something new that fits new requirements (even if that new part is now in a new language)

We have better processes but we don't necessarily have better programmers, and better tooling is no substitute for that.

One thing the parent's post suggests, though, is that we do have better standardization and interoperability. Data normalization is a problem that has largely been solved. So is reading and writing data at scale. Once you've gone to SQL, you presumably won't ever need to go to some other database language or drastically restructure your data in order to rewrite your backend or frontend next time. Similarly, there aren't fifty different schemes for serializing data anymore. JSON is "good enough", every language can now parse it and probably will for the next hundred years. So parts have become more interchangeable. The burden on experienced programmers is less, and it's easier for novice programmers with a shallower base of knowledge to work on pieces of a project even if they don't understand the whole thing. In this sense, tech has become less of a moving target.

We have significantly worse programmers, that’s what better languages and better processes enable. People that would have washed out when the only option was bit twiddling and pointer chasing can now be productive and add value. That’s what progress looks like.

You don't need better programmers to maintain a js project, you only need hireable programmers.

Tooling and processing definitely helps, I have seen it with my own eyes!

(1) Start with experienced programmers who know how to write code

(2) Have them establish good culture: unit testing, end-to-end testing, code coverage requirements, CI (including one on PRs), sane external package policy, single main branch, code reviews, etc...

(3) Make sure that there are experienced programmers have final word over what code goes in, and enough time to review a large part of incoming PRs.

Then you can start hiring other programmers and they will eventually be producing good code (or they'll get frustrated with "old-timers not letting me do stuff" and leave). You can have amazing code which can be refactored fearlessly or upgraded. You could even let interns work on prod systems and not worry about breaking it (although they will take some time to merge their PRs...)

The critical step of course is (3)... If there are no experienced folks guiding the process, or if they have no time, or if they are overridden by management so project can ship faster then the someone disables coverage check or adds crappy PRs which don't actually verify anything. And then formerly-nice project slowly starts to rot...

Tech debt is can come from risk adversity or from taking risks on new shiny things. I think you're right that as long as technology is a moving target, it's always going to be there. To me, the trick is not cornering yourself in a situation where your whole ecosystem is essentially abandoned and not rewriting for the sake of chasing the latest craze. That means parallel re-development, from scratch, of all the existing features, on something like a 10- or 15-year cycle. You want to pick a technology you're certain won't sunset in the next 15 years (with upgrades and further development along the way, of course), then spend a couple years rewriting everything in parallel while still running your old system, test it in every way possible, then blue/green it. I've done this three times in my life for one company on the same piece of large business software.

Companies should think of their software the way automakers or aircraft manufacturers think of their platforms. Once new feature requests are piling up that are just more and more awkward to bolt onto the old system, you have another department that's already been designing a whole new frame and platform for the next decade. Constantly rolling at a steady pace prevents panic. Where this breaks down is where you get things like the 737 MAX.

That makes perfect sense. Extra points if you designed the system to be replaced in time.

Hahah. The last one was a close call, since the entire front end of the system from 2009-2020 was a responsive single page app written in Actionscript 3, to replace the old PHP page system... but we saw the deadline looming about a year in advance and accelerated it.

This is the way, however, integrating with legacy systems then becomes a challenge; a bank's software is never isolated, it has to interface with others, cough up reports for the authorities, etc etc etc.

The green field isn't everything.

If you need 100% parity, that’s a transpiler job.

Son of a COBOL dev... All this virtualization mess, minus the extra Java layer, started back in the 90s, courtesy of Unisys. I remember my dad pulling his hair out when I was in High School, though I did not understand why back then.

I think you get it now though. I've seen this whole industry up close for the last 40 years or so and it's absolutely incredible how we went from a machine with 32 M of RAM and 300 M of storage sufficient to serve 1400 branch offices of a bank to a phone with a very large multiple of that, that can barely serve a single user.

That phone does a lot more than the bank mainframe used to do.

"Busy" and "useful" are entirely different things. Maybe all that extra capability would be better spent elsewhere.

> iphone hangs while trying to match "blu" up with "bluetooth settings"

So many background tasks, much computation

That is some thing that I can't stop thinking about. I get that banking software does more, like online banking, larger transaction volume, more account and loan types, but why is it that we can not run a small to medium bank on a single modern CPU and 1TB of memory?

Eye candy. Endless abstraction layers.

Reply on news.ycombinator.com