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

We are still using buildings and bridges that are more than a century old. Why should we stop using programs that work?



One reason would be that these programs crash, require updates to keep up with industry/process changes and/or will eventually be obsolete in terms of performance or process adequation.

But the knowledge required to fix or update these programs is almost completely owned by the programmers that developed them, who are in the process of retiring or are unwilling to share knowledge for (justified) fear of losing their job.

This creates an unjustifiable dependency for the company, who will have a very hard time finding senior developers to replace the original developers or even recruit <modern language> developers to build a new and more modern system. What happens to the company if the original programmers retire, get sick or leave?

Every project that I know of that focused on replacing mainframes running Cobol quickly reached nightmare-like complexity during the analysis phase - especially because the original developers were uncooperative and the scarce documentation was obsolete - and was replanned to contemplate at least twice the time (and sometimes twice the work/FTE), which will also increase the cost of replacing the technology by a few (tens of) millions...


> Every project that I know of that focused on replacing mainframes running Cobol quickly reached nightmare-like complexity during the analysis phase - especially because the original developers were uncooperative and the scarce documentation was obsolete

That has been my experience as well. It's also the case that business processes get designed around the COBOL code, not just vice versa. Separating out what are actual business requirements from "what we've always done on the mainframe" can be fiendishly difficult, and not just the original developers but the customers can be extremely uncooperative. It takes management coming in and saying "these are the new business processes, they are compliant with the industry standards, and our new software is going to implement them" to get things to actually happen. How that works for a changeover in something like a bank is beyond my experience, though.


There is nothing wrong with using old infrastructure. However, there is something wrong with treating it as a scacred black box.

A company using ancient COBOL code should have people who understand it, but also the ability to test it, and to talk to it from new code.

Once you get to that point, replacing the COBOL is not so hard -- once you have a reason to do it.


It is much harder to modify old software than it is to modify an old building. I've seen projects to modify some small aspect of our system that took 10+ developers six months to implement, but could have been done in an afternoon by a single dev with an IDE, had the project been written in a statically typed language.


COBOL is statically typed. In fact, one of the good features about COBOL is that all fields (variables) have exactly specified lengths, including numbers. You don't just say "I want an integer", you have to say exactly how many digits are in the integer, assuming you use PIC fields (decimal) instead of COMP (binary). Non-numeric fields have exact sizes too, like X(20). It is impossible to have a buffer overflow in COBOL.


A given COBOL module is statically typed, but a typical (in my experience) COBOL application is made up of many modules and there is no type checking between them.


The equivalent would probably be rather (literally) byzantine sewage and water systems from the middle ages in very old cities like Istanbul ;)

They're everywhere, they do.. something.., and nobody can replace them just all at once. Even if you replace some of them, the remaining part still means your system gets swamped by the old mess.




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

Search: