Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Watsonx: IBM's code assistant for turning COBOL into Java

pcmag.com

Post reply on HN
Print view View original

131–140 of 186 posts

Re: Watsonx: IBM's code assistant for turning COBOL into Java

#131

Post by rcbdev »

haolez wrote: post #123
bluedino wrote: post #50

Not sure what's worse, depending on LLMs, or IBM to fix your COBOL project.

I know of a retail company that hired IBM to get rid of its huge Clipper code base (around 1.5MM LOC). IBM told them that they would get rid of all Clipper in 2 years. 5 years later, IBM has a few containers (physical containers) in this company's parking lot, adapted as offices, full of engineers doing maintenance and new features on the Clipper code base.

During my time at the company we never once talked about what the customer actually needed or wanted. Your story confirms my suspicion that this type of sales-driven development is just how IBM operates anywhere.

The truth is, IBM has been bean counted to death. Their turnover rates are incredibly high, employees have to deal with utilization targets that they can't meaningfully do anything about and lines of communication are incredibly dysfunctional. Their global headcount has been quietly but steadily declining since the dawn of the 2000s and their whole EMEA business is riding on having good ties to the right people in the public sector.

The result is that IBM's customers are increasingly unhappy. I do not see how this company is going to survive in its current form.

Re: Watsonx: IBM's code assistant for turning COBOL into Java

#132

Post by noduerme »

jacquesm wrote: post #75
Nextgrid wrote: post #67

Earlier quoted context omitted.

> 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…

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 su…

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.

Re: Watsonx: IBM's code assistant for turning COBOL into Java

#133

Post by rodgerd »

ufmace wrote: post #21

The article title is clickbaity, but the actual point is the proposal of using LLMs to translate large amounts of legacy COBOL systems to more modern languages like Java. Doesn't seem terribly useful to me. I expect you could get a 90% solution faster, but the whole challenge with these projects is how to get that last bit of correctness, and how to be confident enough in the correctness of it to actually use it in P…

I once did some work looking into whether I could help move some subsystems off a zOS system with the help of an HP pitch that was a combo of auto-translation plus contractors checking. It was an attractive idea. I've also looked at CICS/COBOL environments that run on *ix systems, with a similar view.

The problem is that once you start working through your system, it's a lot harder than people making this sort of pitch would like you to believe. People writing CICS/COBOL now will likely be writing well-structured code with sensible names, taking advantage of threading and with proper interfaces between different programs. They're shipping data on and off the mainframe with maybe REST maybe SOAP maybe MQ. They're storing their data in DB2.

But people writing the parts of the codebase 20 years ago were still regularly dropping down to 390 assembler to get it to run fast enough and, guess what, that code is still there and still being extended. Maybe they were using DB2, maybe they were using VSAM files. They were using maybe MQ, maybe SNA, maybe TCP sockets with bespoke protocols to interact with the outside world. Programs might have just been talking to each other by banging on memory regions.

If they were working in the 80s and 90s, they had all that, but they were probably experimenting with 4GLs that promised to let anyone build programs. Some of those 4GLs are still around, probably not running CICS. And there was a lot of assembler. Maybe some non-CICS workloads. Passing things around via memory regions would be as often as not.

Oh, and the people who understood any of the business processes that got turned into code are long, long gone. They got laid off to justify the computerisation. The only people who know why things happen a particular way are the people who wrote the code, if they're still alive and working for you.

And so on and so forth. The reason mainframe code bases are hard to pick apart are because they're 50 years of different languages and runtimes and databases and performance tradeoffs and opinions about what good practise is. This is hard. An "AI" COBOL to Java translator isn't 80 or 90% of the job and honestly IBM should be embarrassed to be the ones suggesting that it is.

Re: Watsonx: IBM's code assistant for turning COBOL into Java

#134

Post by noduerme »

jacquesm wrote: post #129
wongarsu wrote: post #126

Earlier quoted context omitted.

> 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…

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.

Re: Watsonx: IBM's code assistant for turning COBOL into Java

#135

Post by tootie »

grammie wrote: post #91
IshKebab wrote: post #53

Earlier quoted context omitted.

I'm pretty sure there's already a system to transpile COBOL to Java without resorting to LLMs.

Heirloom computing where I am cto does this using transpilers with 100% automated transpilation. Using LLMs for an entirely deterministic domain borders on the insane. This is just marketing bs but we get asked about it and what our plan is to counter it all the time. Explaining that using Gen-ai and LLMs for what is a well understood compiler/transpiler problem that is already solved just seems to be too difficult f…

It's almost sad. Watson defeated Ken Jennings at Jeopardy 12 years ago and today IBM are nowhere in the AI race. They bet the farm on the exact right domain ahead of the competition and still failed.

Re: Watsonx: IBM's code assistant for turning COBOL into Java

#136

Post by nunez »

Literally today I was checking out of a rental car center and the checkout person loaded up an emulated green screen mainframe program to complete the process.

I know for sure that Avis's reservation system runs on mainframe.

To me, that means that the business logic of rental car checkout and return is so complicated and/or nuanced, it is cheaper for rental car companies to find/retain mainframe developers to keep these running than it would be to re-platform onto commodity hardware.

Also, given that basically every industry is powered by a handful of mainframes, it is surprising that COBOL/Fortran developers aren't making insane money like I thought they were.

Re: Watsonx: IBM's code assistant for turning COBOL into Java

#137

Post by nunez »

hnlmorg wrote: post #112
JackFr wrote: post #72

Earlier quoted context omitted.

That is not any COBOL I’ve seen. Straightforward, well documented and comprehensively specified and tested. When we needed changes (this was back office clearing stuff for a bank) they wouldn’t even talk to us until we specced out the changes we wanted in writing and often the specs we submitted would come back with requests for clarification. This was like the opposite of agile, but I don’t recall any bugs or defect…

This was my experience too. Modern software engineers would hate that kind of red tape because we've been conditioned to want shorter feedback loops. Heck, I hated it back then too and I wasn't even accustomed to seeing my results instantly like I am now. It takes a special kind of person to enjoy the laborious administrative overhead of writing detailed specs before you write even a single line of code.

Kind of reminds me of taking pure CS101 (I.e. no programming language; just theory and sacrifice)

Re: Watsonx: IBM's code assistant for turning COBOL into Java

#138

Post by nunez »

exhilaration wrote: post #70
tobyjsullivan wrote: post #8

Earlier quoted context omitted.

I’d be curious to know how we’re defining “overpaying” here. These companies have effectively accrued 50+ years of technical debt (they could have migrated off COBOL decades ago). Meanwhile, based on my limited experience with these industries, I’d be surprised if they even offer market rates to new hires.

The answer is India. Just Google India and COBOL, there's tons of schools teaching it. So if Watson doesn't work out for you, IBM is happy to sell you offshore consulting services the bridge the gap! This is all win-win for IBM -- you can can keep your $200 million mainframe service contract or hire IBM to (kinda? maybe?) move you to something more modern.

Can confirm. When I was in Hyderabad in 2019, I saw signs for a few schools marketing COBOL and FORTRAN.

Re: Watsonx: IBM's code assistant for turning COBOL into Java

#139

Post by girvo »

rcbdev wrote: post #131
haolez wrote: post #123

Earlier quoted context omitted.

I know of a retail company that hired IBM to get rid of its huge Clipper code base (around 1.5MM LOC). IBM told them that they would get rid of all Clipper in 2 years. 5 years later, IBM has a few containers (physical containers) in this company's parking lot, adapted as offices, full of engineers doing maintenance and new features on the Clipper code base.

During my time at the company we never once talked about what the customer actually needed or wanted. Your story confirms my suspicion that this type of sales-driven development is just how IBM operates anywhere. The truth is, IBM has been bean counted to death. Their turnover rates are incredibly high, employees have to deal with utilization targets that they can't meaningfully do anything about and lines of communi…

And the R&D guys at IBM are 1) brilliant and 2) smart enough to stay well away from IBM proper as much as they can, at least when I partnered with some, some years ago

Re: Watsonx: IBM's code assistant for turning COBOL into Java

#140

Post by jacquesm »

noduerme wrote: post #132
jacquesm wrote: post #75

Earlier quoted context omitted.

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 su…

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 existi…

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