Hacker News Reader

Comment by RcouF1uZ4gsC | Hacker News Reader

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

View on HN

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.

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

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

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.

Reply on news.ycombinator.com