3 ms·

>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 widel

>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.

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.