- cross-posted to:
- [email protected]
- cross-posted to:
- [email protected]
It’s not the 1st time a language/tool will be lost to the annals of the job market, eg VB6 or FoxPro. Though previously all such cases used to happen gradually, giving most people enough time to adapt to the changes.
I wonder what’s it going to be like this time now that the machine, w/ the help of humans of course, can accomplish an otherwise multi-month risky corporate project much faster? What happens to all those COBOL developer jobs?
Pray share your thoughts, esp if you’re a COBOL professional and have more context around the implication of this announcement 🙏
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?