Watsonx: IBM's code assistant for turning COBOL into Java • Hacker News Board

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

#181

Post by exabrial » Mon, Dec 04, 2023, 3:26 PM UTC

COBOL -> Misses the entire point of a legacy codebase. COBOL is not the problem.

The actual problem is the missing knowledge from the engineers the CEO downsized and sent their work overseas. This boils down to three things:

1) figuring out the call patterns

2) figuring out the architecture

3) figuring out the business logic

This is also why cowboy coders are dangerous in your organization, while having corporate standards and making your codebase self-consistent (aka "Clean Code") is the most valuable thing you can spend your time on.

source: I made a bunch of dollar bills working on Java / EIS COBOL systems that needed to interact at wire speed, while not paying Big Blue for their EIS Gateway Software.

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

#182

Post by ukuina » Mon, Dec 04, 2023, 3:34 PM UTC

throwaway98797 wrote: post #180

Stratoscope wrote: post #166

Earlier quoted context omitted.

Like many large companies, IBM discourages us from engaging in "social media" (which I guess includes HN) on work-related questions. I felt that I could make an exception for the minor correction of the product name. It's probably not appropriate for me to comment here on how I like the job. I would be happy to discuss it privately with you or anyone else who is curious. My email address is in my profile; feel free t…

not op appreciate the comment this exchange is what i show young people to demonstrate why you should never work for such companies (not signaling out yours specifically) human want to be human (tho a buddy of mine worked there with great benefits & $)

Why is it bad for a company to have a social media or online comment policy?

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

#183

Post by octokatt » Mon, Dec 04, 2023, 5:32 PM UTC

hnbear wrote: post #73

Having had to support and migrate COBOL in a big financial the problems weren’t really related to the COBOL, but instead were: 1. The mainframe costs and support. These can be mitigated with migration to a platform like Microfocus to emulate it, but be careful you don’t replace your ultra reliable mainframe with some flakey Windows servers. 2. The embedded business logic. Within the 50-60 years of code there’s a ton…

I worked at an insurance company where a giant COBOL mainframe squatted in the middle of their data systems like a toad*.
During the last major attempt to remove the system, they got close. A team of good engineers worked over two years painstakingly updating documentation, transferring and rebuilding systems, and got to the Go-No-Go meeting. They explained everything to the single SME in their 60's who knew best where the bodies were buried, and she seemed satisfied.
When they got to the end of the Go-No-Go, she asked, "Where did you put our payroll?"
COBOL literally sent everyone their paychecks. It was enough of a deathblow to find something that important had been overlooked, the project was abandoned.

*Oracle Toad was in there too, but it felt snappy instead of squatty compared to the COBOL.

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

#184

Post by jacquesm » Mon, Dec 04, 2023, 8:28 PM UTC

mrweasel wrote: post #163

jacquesm wrote: post #130

Earlier quoted context omitted.

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

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

#185

Post by theamk » Mon, Dec 04, 2023, 8:48 PM UTC

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.

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

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

#186

Post by stonogo » Tue, Dec 05, 2023, 12:52 AM UTC

dr_kiszonka wrote: post #155

stonogo wrote: post #82

Earlier quoted context omitted.

There are plenty of COBOL devs; they're just not in the American labor market.

Would bumping starting salaries for Cobol devs to 150k, resolve it in the US? (I am assuming banks could afford it.)

No, since that's not too much higher than starting salaries for Python programming at a medium-sized research institute, and there's no clear career progression for COBOL programmers.