←back to thread

127 points Anon84 | 2 comments | | HN request time: 0.533s | source
Show context
spindle ◴[] No.38511433[source]
I believe that practically the whole barrier to getting rid of legacy COBOL systems is testing the replacement system. Of course it's possible but it's very very expensive ... I don't have numbers for how expensive, but I've worked on financial software in COBOL on a mainframe, and nothing was the least bit abstruse or scary or difficult about it except the worry that our test suite might not be comprehensive, no matter how much we worked on it (and we worked on the test suite about the same amount as we worked on all the rest of the code put together). But at least our test suite appeared to cover all the cases that eventuated when we ran our COBOL code. How confident would be be that it would cover all the cases that eventuated when we ran translated code? THAT is the problem (or at least was for us). Nothing at all to do with whether translating COBOL can be made easier.
replies(1): >>38512215 #
1. wokkel ◴[] No.38512215[source]
No, getting a 100% equivalent working Java system is trivial. But the goal is having something that looks like it was Java from the start not Java as written by a cobol expert. So proper use of classes. Not al globals. Sensible naming etc. The real cost is in maintenance of the code: having in idiomatic Java could help. Translating to idiomatic Java is very hard
replies(1): >>38514169 #
2. fbdab103 ◴[] No.38514169[source]
I think those companies would kiss you on the mouth and do any unspeakable acts you requested were you able to promise a 100% equivalent system in Java. There is a ton of industry experience in turning working-but-trash Java into something more maintainable.