Hacker News new | past | comments | ask | show | jobs | submit login

Until you need to update it to cope with Y2K or Y2K38 or GDPR or some other external factor...



I get the feeling that COBOL won't have much of a Y2K38 problem, but the elevator and HVAC are suspect.


How ironic, isn't it. For some reason, everything written before the 90's still manages to work on particular platforms while everything after has been deprecated month by month.


Survivorship bias. The ones that broke aren't around to compare.


True. But changes of that natures vs reimplementing the entire system?


I agree that making the change is preferable to reimplementing. Just saying you can’t assume that an old and battle tested codebase is an ops problem rather than a dev problem.

There’s going to be some point where you’ll be glad to have original specs and docs and source code on hand (along with a good COBOL dev) so you don’t have to decompile and reverse engineer the damn thing. (Which IIRC had to be done for a relatively large percentage of COBOL-era systems updated for Y2K.)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: