3 ms·

Why? That Cobol code has decades of bug fixing in it, and obviously it works. Rewriting it in another language needs to be "bug by bug" compatible anyway (eg "

Why? That Cobol code has decades of bug fixing in it, and obviously it works. Rewriting it in another language needs to be "bug by bug" compatible anyway (eg "use zero for unknown birthday") and it will most likely introduce new bugs. In the end the language isn't as important as the tooling around it, and I bet there are modern compilers and debuggers available.

blitzar 2y ago
Ahh I remember my first corporate rewrite. $6 mil, 12 months, the legacy systems will be all gone. 7 years later, $140mil spent (dozens of junior worker lambs fed to the slaughter for the good of the bosses) and now there are two systems running in parallel - the new and the old both fully staffed and supported. It's time to consider upgrading the new legacy system. Cutting waste was the mantra then too.
- darthrupert 2y ago
  Rewrites definitely need skills and good processes. And most of all, they need support from all levels and the original team. For most things we of course have the free markets for doing the culling: old things die completely and are replaced with new ones without any connection to the old ones. But some of these systems aren't in that world and cannot benefit from those processes.
darthrupert 2y ago
Answer to why is so that we don't end up with systems that need can only be replaced by a phoenix process. I.e. let it burn and hope something rises from the ashes.
- flohofwoe 2y ago
  The alternative is to just simply continue maintaining the working COBOL system. If a programmer can't find their way around in a different programming language then they really shouldn't call themselves programmers. The original COBOL system most likely has a much simpler structure than any modern rewrite would have (if the modern rewrite follows modern 'best practices' which tends to obscure the actual work under layers and layers of abstraction). Instead migrate that old COBOL system to new hardware (in emulators if needed), put a modern web-based UI on top of it, keep adding to the documentation and maintenance procedures, add tests written in modern languages, add a modern build infrastructure, etc etc... but think twice before replacing the part that does the actual work (there is actually a good chance the 'bug' is just in an UI layer that was added later, it may not know that a zero-birthdate should be displayed as 'unknown birthdate'). > I.e. let it burn and hope something rises from the ashes. That's exactly what a rewrite in another language would be.

blitzar 2y ago

Ahh I remember my first corporate rewrite. $6 mil, 12 months, the legacy systems will be all gone. 7 years later, $140mil spent (dozens of junior worker lambs fed to the slaughter for the good of the bosses) and now there are two systems running in parallel - the new and the old both fully staffed and supported. It's time to consider upgrading the new legacy system. Cutting waste was the mantra then too.

darthrupert 2y ago
Rewrites definitely need skills and good processes. And most of all, they need support from all levels and the original team. For most things we of course have the free markets for doing the culling: old things die completely and are replaced with new ones without any connection to the old ones. But some of these systems aren't in that world and cannot benefit from those processes.

darthrupert 2y ago

Answer to why is so that we don't end up with systems that need can only be replaced by a phoenix process. I.e. let it burn and hope something rises from the ashes.

flohofwoe 2y ago
The alternative is to just simply continue maintaining the working COBOL system. If a programmer can't find their way around in a different programming language then they really shouldn't call themselves programmers. The original COBOL system most likely has a much simpler structure than any modern rewrite would have (if the modern rewrite follows modern 'best practices' which tends to obscure the actual work under layers and layers of abstraction). Instead migrate that old COBOL system to new hardware (in emulators if needed), put a modern web-based UI on top of it, keep adding to the documentation and maintenance procedures, add tests written in modern languages, add a modern build infrastructure, etc etc... but think twice before replacing the part that does the actual work (there is actually a good chance the 'bug' is just in an UI layer that was added later, it may not know that a zero-birthdate should be displayed as 'unknown birthdate'). > I.e. let it burn and hope something rises from the ashes. That's exactly what a rewrite in another language would be.