221
[DISCUSS] IBM using LLMs to convert COBOL to Java
(techcrunch.com)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 23 Aug 2023
221 points (96.6% liked)
Technology
35158 readers
127 users here now
This is the official technology community of Lemmy.ml for all news related to creation and use of technology, and to facilitate civil, meaningful discussion around it.
Ask in DM before posting product reviews or ads. All such posts otherwise are subject to removal.
Rules:
1: All Lemmy rules apply
2: Do not post low effort posts
3: NEVER post naziped*gore stuff
4: Always post article URLs or their archived version URLs as sources, NOT screenshots. Help the blind users.
5: personal rants of Big Tech CEOs like Elon Musk are unwelcome (does not include posts about their companies affecting wide range of people)
6: no advertisement posts unless verified as legitimate and non-exploitative/non-consumerist
7: crypto related posts, unless essential, are disallowed
founded 5 years ago
MODERATORS
What pisses me off about many such endeavors is, that these companies always want big-bang solutions, which are excessively hard to plan out due to the complexity of these systems, so it's hard to put a financial number on the project and they typically end up with hundreds of people involved during "planning" just to be sacked before any meaningful progress could be made.
Instead they could simply take the engineers they need for maintenance anyway, and give them the freedom to rework the system in the time they are assigned to the project. Those systems are - in my opinion - basically microservice systems. Thousands of more or less small modules inter-connected by JCL scripts and batch processes. So instead of doing it big bang, you could tackle module by module. The module doesn't care in what language the other side is written in, as long as it still is able to work with the same datastructure(s).
Pick a module, understand it, write tests if they are missing, and then rewrite it.
After some years of doing that, all modules will be in a modern language (Java, Go, Rust, whatever) and you will have test coverage and hopefully even documentation. Then you can start refactoring the architecture.
But I guess that would be too easy and not enterprisy enough.
You just handwaved thousands of processes like it's easy .. lol.
I said it takes years. The point is that you can do it incremental. But that typically doesn't fit with the way enterprises want things done. They want to know a beginning, a timeline and a price. Since they don't get that, they simply give up.
But it's dumb, since those systems run already and have to keep running. So they need to keep engineers around that know these systems anyway. Since maintenance work likely doesn't take up their time, they could "easily" hit two birds with one stone. The engineers have a fulltime job on the legacy system (keeping them in the loop for when an incident happens without having to pull them out of other projects then and forcing them into a context switch) and you slowly get to a modernized system.
Not doing anything doesn't improve their situation and the system doesn't get any less complex over time.
I think you vastly overestimate the separability of these systems.
Picture 10,000 lines of code in one method, with a history of multiple decades.
Now picture that that method has buried in it, complex interactions with another method of similar size, which is triggered via an obscure side-effect.
Picture whole teams of developers adding to this on a daily basis in realtime.
There is no "meaningful progress" to be made here. It may offend your aesthetic sense, but it's just the reality of doing business.
What's the alternative in your opinion?
Not doing anything and keep fiddling around in this mess for the next 20 years?
Continue trying to capture this problem big-bang, which means not only dealing with one such unmaintainable module but all of them at once?
Will every module be a piece of cake? Hell no. But if you never start anywhere, it doesn't get better on its own.
The alternative is to continue with a process that's been demonstrably successful, despite it offending your sensibilities.
Banks are prepared to pay for it. People are prepared to do it. It meets the business needs. Change is massively high-risk in a hugely conservative industry.
And what is that successful process?