5 ms·

Cobol is mostly likely around because no one knows exactly what the code does. Missing design documents & decisions don't help either. Companies making money a

Cobol is mostly likely around because no one knows exactly what the code does. Missing design documents & decisions don't help either. Companies making money are risk adverse, they won't risk killing their golden goose over a rewrite, it's often companies that are not making money that go on massive rewrites believing that new tech will give them the Midas touch towards profit.

RcouF1uZ4gsC 7y ago
>Missing design documents & decisions don't help either. Even if you had the original design documents, it is very likely that the code that runs now has widely diverged from the design documents in the past 50 years. In addition, being risk averse for this kind of code is likely a good thing. With a rewrite, the best you can hope for is to do what you are doing now without running into bugs. At worst, you have lost a lot of money and reputation and may become bankrupt. The risk/reward tends to favor "if it ain't broke, don't fix it."
- ethbro 7y ago
  The benefit of old code is that you've usually found all the bugs in it. And if you've already found all the bugs, and it's performant enough, why would you ever rewrite it? Sure, there's a maintainability issue, specifically with available developer talent. But I feel like shepherding a mature, battle-tested codebase probably is more of an ops than a dev problem.
  - gshdg 7y ago
    Until you need to update it to cope with Y2K or Y2K38 or GDPR or some other external factor...
    - ethbro 7y ago
      True. But changes of that natures vs reimplementing the entire system?
      - gshdg 7y ago
        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.)
    - protomyth 7y ago
      I get the feeling that COBOL won't have much of a Y2K38 problem, but the elevator and HVAC are suspect.
      - noobermin 7y ago
        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.
        babyloneleven 7y ago
        Survivorship bias. The ones that broke aren't around to compare.
0x445442 7y ago
I had a contract about 10 years ago for a major city's water department. The contract was to convert an internal application for customer billing, written in COBOL running on the mainframe to a web application backed by Oracle. When I started gathering requirements from the city's rep who was my point of contact I asked them for any documentation they had such as use cases, functional specs etc. All they could provide was the original COBOL source code bound up in those huge 17"x14" binders; the one's that have the holes along each side from the old dot matrix printers with every other line having that faint light green background. Well I'd never seen COBOL in my entire live and I could only look at the code for about an hour before my eyes started to bleed. Fortunately I was able to get restricted access to the system and it ended up being pretty easy to just reverse engineer the thing by mapping each green screen of the app to a corresponding web page. In the end I didn't need any original code or documentation to do the job.
- HillaryBriss 7y ago
  > All they could provide was the original COBOL source code ... I worked a contract for an android app like that: only source, no requirements, no tests, no docs. A little bit of incomplete commentary in the code. I would build it, run it, see it crash and hope the fixes I made didn't eliminate some important feature. IDK. Isn't that the way everything works now?
- KC8ZKF 7y ago
  Is your code still running? Did it suffer significant downtime? Did anything else break because of the new code? Did anyone do without water?
  - 0x445442 7y ago
    Yes, no, no and no... AFAIK :)
- stefco_ 7y ago
  I almost did a FORTRAN subcontracting gig like this to translate an old but accurate simulation of a mechanical system to Python. I literally got a binder full of FORTRAN to start with, though eventually (to my great relief) the guy I was going to work under got me digital copies. Didn't pan out anyway, though, since he didn't win the contract.
RandomTisk 7y ago
Working at a large bank, a Cobol programmer once told me the use cases are very narrow, but that it's extremely dependable once deployed into production. To be a little blunt though, to process statements and track transactions with high dependability, it works well when you repel anyone with a low attention span or someone has a strong desire for learning new languages and programming paradigms. You need and want programmers who are more about making the same kind of sausage day in day out rather than innovation because at the end of the day, the bank statement and transactions are trivial but extremely important problems. In other words, it's an older programmer's workshop.
- SeanDav 7y ago
  This comment appears to be fairly insulting. Is it implying that older programmers can't / won't / wouldn't like doing innovative programming? Is it implying that if you like doing innovative programming and learning more about new languages and your craft, you must have a short attention span? It is also rather naive if it is believed that anything other than a tiny fraction of programming in the real world is actually innovative.
  - RandomTisk 7y ago
    Don't know, but most of the Cobol programmers I knew of there were not recent college grads.

RcouF1uZ4gsC 7y ago

>Missing design documents & decisions don't help either. Even if you had the original design documents, it is very likely that the code that runs now has widely diverged from the design documents in the past 50 years. In addition, being risk averse for this kind of code is likely a good thing. With a rewrite, the best you can hope for is to do what you are doing now without running into bugs. At worst, you have lost a lot of money and reputation and may become bankrupt. The risk/reward tends to favor "if it ain't broke, don't fix it."

ethbro 7y ago
The benefit of old code is that you've usually found all the bugs in it. And if you've already found all the bugs, and it's performant enough, why would you ever rewrite it? Sure, there's a maintainability issue, specifically with available developer talent. But I feel like shepherding a mature, battle-tested codebase probably is more of an ops than a dev problem.
- gshdg 7y ago
  Until you need to update it to cope with Y2K or Y2K38 or GDPR or some other external factor...
  - ethbro 7y ago
    True. But changes of that natures vs reimplementing the entire system?
    - gshdg 7y ago
      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.)
  - protomyth 7y ago
    I get the feeling that COBOL won't have much of a Y2K38 problem, but the elevator and HVAC are suspect.
    - noobermin 7y ago
      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.
      - babyloneleven 7y ago
        Survivorship bias. The ones that broke aren't around to compare.

0x445442 7y ago

I had a contract about 10 years ago for a major city's water department. The contract was to convert an internal application for customer billing, written in COBOL running on the mainframe to a web application backed by Oracle. When I started gathering requirements from the city's rep who was my point of contact I asked them for any documentation they had such as use cases, functional specs etc. All they could provide was the original COBOL source code bound up in those huge 17"x14" binders; the one's that have the holes along each side from the old dot matrix printers with every other line having that faint light green background. Well I'd never seen COBOL in my entire live and I could only look at the code for about an hour before my eyes started to bleed. Fortunately I was able to get restricted access to the system and it ended up being pretty easy to just reverse engineer the thing by mapping each green screen of the app to a corresponding web page. In the end I didn't need any original code or documentation to do the job.

HillaryBriss 7y ago
> All they could provide was the original COBOL source code ... I worked a contract for an android app like that: only source, no requirements, no tests, no docs. A little bit of incomplete commentary in the code. I would build it, run it, see it crash and hope the fixes I made didn't eliminate some important feature. IDK. Isn't that the way everything works now?
KC8ZKF 7y ago
Is your code still running? Did it suffer significant downtime? Did anything else break because of the new code? Did anyone do without water?
- 0x445442 7y ago
  Yes, no, no and no... AFAIK :)
stefco_ 7y ago
I almost did a FORTRAN subcontracting gig like this to translate an old but accurate simulation of a mechanical system to Python. I literally got a binder full of FORTRAN to start with, though eventually (to my great relief) the guy I was going to work under got me digital copies. Didn't pan out anyway, though, since he didn't win the contract.

RandomTisk 7y ago

Working at a large bank, a Cobol programmer once told me the use cases are very narrow, but that it's extremely dependable once deployed into production. To be a little blunt though, to process statements and track transactions with high dependability, it works well when you repel anyone with a low attention span or someone has a strong desire for learning new languages and programming paradigms. You need and want programmers who are more about making the same kind of sausage day in day out rather than innovation because at the end of the day, the bank statement and transactions are trivial but extremely important problems. In other words, it's an older programmer's workshop.

SeanDav 7y ago
This comment appears to be fairly insulting. Is it implying that older programmers can't / won't / wouldn't like doing innovative programming? Is it implying that if you like doing innovative programming and learning more about new languages and your craft, you must have a short attention span? It is also rather naive if it is believed that anything other than a tiny fraction of programming in the real world is actually innovative.
- RandomTisk 7y ago
  Don't know, but most of the Cobol programmers I knew of there were not recent college grads.