Hacker News Reader

Comment by wtetzner | Hacker News Reader

> COBOL programs have history. They were changed in '77 and then the change was reverted in '79 and then again in '84. Nobody really remembers why.

I wonder how different it would be if they had a good source control system (and used it). Would you be able to look at the history and understand why the changes were made, or would you just get a bunch of commit messages like "made update" or "reverted earlier change"?

View on HN

Having worked on the PL/1 and Assembler that formed the core accounting systems of a bank: yes.

Not only did I have source control I had flow diagrams of the entire system for all points in the chain. My code reviews had me doing line-by-line justifications. I wrote tests.

Just because the technology and practitioners are old it doesn't mean they don't know what they're doing.

Generally they invented whatever "you" are reinventing the first time around.

COBOL was used for more mundane tasks - a lot of data loading, formatting, batches of all kinds. Not all of which seemed so important when they were written, but that ended up being a plug nobody wants to take the risk of disconnecting.....

If they're still run, they're still important if not crucial.

I don't think they do data loading and batch processing on stuff they don't need.

Exactly. But sometimes they were built as a "quick patch, we'll do this right later" and then improved and changed and.... you see the picture.

> Just because the technology and practitioners are old it doesn't mean they don't know what they're doing.

I certainly didn't mean to imply that. It's more that many people now don't do a good job with that stuff, so I was curious if it would have been better then.

In my professional experience, code comments and commit messages only cursorily reflect the change in the business logic that prompted the modifications. I suspect this is because the knowledge of the client's business logic is concentrated in the product managers' domain and not in the programmers' domain. All of the back and forth emails with the customer don't get included in our SCM.

Imagine they used jira, confluence, and git. It would still be a huge no! Code archeology is a real necessity even on a <10 year old system. The best way to find out about something is to have a chat with a ‘historian’ who has been with the company for 10+ years.

It depends on team culture at a time.

There are teams which require all changes come via defined channel (like bug tracker or special email), and which put ticket # in each commit (like Gitlab -- see the "closes #..." at the commit message [0])

But many teams have no procedure, or the procedure is optional -- and there you can easily get "made update" commits.

https://gitlab.com/gitlab-org/gitlab/-/merge_requests/56794

I worked at 3 different companies in the mid 1990s that had teams actively working on COBOL systems and they were all using mainframe based version control systems. I think the issue at this point is whether those version control systems are still being maintained and those orgs are continuing to pay for the licenses for those systems, probably during years where you weren't even planning on using them.

Reply on news.ycombinator.com