3 ms·

It would actually be better if we replaced x million lines of COBOL with x million lines of COBOL. For many reasons: 1. it would run on a modern environment in

by EdiX 8y ago

It would actually be better if we replaced x million lines of COBOL with x million lines of COBOL. For many reasons: 1. it would run on a modern environment instead of a weird mainframe OS using a weird database 2. it would use modern coding conventions such as local variables and control structures instead of goto 3. it wouldn't be x million lines after you remove all the dead and duplicate code. These are codebases have been developed for 3 decades with the principle "we don't know how any of this old shit works, don't touch anything you don't need to" But yes, you would also get a lot of advantages from porting everything to a modern programming language with good tooling.

tluyben2 8y ago
I agree with you somewhat there; you mean refactor instead of rewrite and yes, I believe that is a better choice. But the problem is not language related; Joel Spolsky said it with far smaller and more modern codebases, but, as you even indicate within #3, 100000s of changes were done in the code over 30 years by people who did not understand the full system or, often, did not even understand the local parts they are editing fully. A lot of changes in legacy code, but let's not kid ourselves, also in modern code, depend on 'things' the programmer deemed right at that moment. Then after testing (even testing in practice with people's money), now after unittests (or in practice, with people's money), too much of the business logic/functionality depends on bad code. Code that is off-by-one that isn't discovered for decades or at all is not unheard of for instance because that routine is only triggered for a specific insurance policy only 100 people have and for those 100 the bug actually gives back the right answer. It would require deep understanding of all the corner cases and that's why it's often just not rewritten. We were working, around 2000, on partially porting a Cobol+Fortran insurance system (which was an 'integration' of systems acquired by acquisition over the years) to Java (yes, EJBs..... ..... ..... the sins of my youth...). The work was mostly 20 people working for months on creating all the encoded rules into spreadsheets and, in a much shorter time, us translating those to Java. This particular piece was done because the company wanted to webify that part of the system. I am not sure if the modern versions of 'software mainframes' or modern hardware mainframes would be fast enough to handle web with the old code running?
- ams6110 8y ago
  The thing about most old COBOL is that there is very little shared code. There are things called "copybooks" which are snippets that get copied into your program at compile time, but they are not "shared" code. So you have much less chance of affecting anything else when you change a COBOL program. Most are written to perform a single transaction or generate a single report or screen, and are entirely self-contained.
pjmlp 8y ago
There are modern environments for COBOL, it has even been updated to OO and such. http://www.fujitsu.com/global/products/software/developer-tool/netcobol/index.html http://www.fujitsu.com/global/products/software/developer-to... https://www.microfocus.com/products/visual-cobol https://www.microfocus.com/products/visual-cobol

by EdiX 8y ago

tluyben2 8y ago

I agree with you somewhat there; you mean refactor instead of rewrite and yes, I believe that is a better choice. But the problem is not language related; Joel Spolsky said it with far smaller and more modern codebases, but, as you even indicate within #3, 100000s of changes were done in the code over 30 years by people who did not understand the full system or, often, did not even understand the local parts they are editing fully. A lot of changes in legacy code, but let's not kid ourselves, also in modern code, depend on 'things' the programmer deemed right at that moment. Then after testing (even testing in practice with people's money), now after unittests (or in practice, with people's money), too much of the business logic/functionality depends on bad code. Code that is off-by-one that isn't discovered for decades or at all is not unheard of for instance because that routine is only triggered for a specific insurance policy only 100 people have and for those 100 the bug actually gives back the right answer. It would require deep understanding of all the corner cases and that's why it's often just not rewritten. We were working, around 2000, on partially porting a Cobol+Fortran insurance system (which was an 'integration' of systems acquired by acquisition over the years) to Java (yes, EJBs..... ..... ..... the sins of my youth...). The work was mostly 20 people working for months on creating all the encoded rules into spreadsheets and, in a much shorter time, us translating those to Java. This particular piece was done because the company wanted to webify that part of the system. I am not sure if the modern versions of 'software mainframes' or modern hardware mainframes would be fast enough to handle web with the old code running?

ams6110 8y ago
The thing about most old COBOL is that there is very little shared code. There are things called "copybooks" which are snippets that get copied into your program at compile time, but they are not "shared" code. So you have much less chance of affecting anything else when you change a COBOL program. Most are written to perform a single transaction or generate a single report or screen, and are entirely self-contained.

pjmlp 8y ago

There are modern environments for COBOL, it has even been updated to OO and such. http://www.fujitsu.com/global/products/software/developer-tool/netcobol/index.html http://www.fujitsu.com/global/products/software/developer-to... https://www.microfocus.com/products/visual-cobol https://www.microfocus.com/products/visual-cobol