Comment by m0nastic | Hacker News Reader

Comment by m0nastic | Hacker News Reader

This is both awful, somehow unsurprising, and COBOL is a piss poor scapegoat.

I've talked on here in the past about how crazy it is that some of my customers had huge financial systems that were written in COBOL, quietly still plugging away.

The most important of which is a system which processes billions of dollars of transactions a day, and has done so since the early 70's (when they purchased the what was then off-the-shelf software). You can imagine what a maintenance nightmare it must be (both because it's old, very important, and written in a programming language which predates the cotton gin).

Assuming that they can't just rewrite the system (which might be a reality), they can certainly sit down a bunch of developers and have them learn COBOL. COBOL isn't even a particularly difficult language, we were writing pretty decently-sized programs after a few months in high school (and if the system is that old, it's probably not even using any fancy language features).

If only the military had some means by which they could take people without past exposure to some skillset and train them to be competent at that skillset. Maybe part of that training could involve having to climb over a wall, or some sort of rope course.

It might not even be an issue of training COBOL programmers. I'm aware of more than one large-scale legacy system that people "somehow" lost the source code for.

Which means fixing bugs means disassembly, hot patching, and keeping your fingers crossed. And if you're lucky and the place is incapable of learning, they'll then lose all documentation for the patch, too. Fixing anything is a nightmare. On the upside, if you can stomach it, there are nice consulting fees to be had.

(I'm not aware if the Pentagon lost source code - my experience is with civilian systems)

> Which means fixing bugs means disassembly, hot patching, and keeping your fingers crossed.

This sounds like something with extremely high overhead, that would benefit from scale. That is to say, instead of trying to reverse-engineer and patch each module every time you need to make a change, just:

1. run the entire project through a decompiler, making sure that each generated code file on its own recompiles to something that works when linked back together with the rest of the existing modules;

2. and then use that decompiled result as the new codebase, and start refactoring.

Who knows how big the program is? Perhaps it can reach a size where refactoring is just way more expensive than patching as needed.

In a reasonable world, yes. In a world where IT is a cost center, this is what happens:

1) People work around it as much as possible.

2) When the pain is unbearable, you bring in a high-priced consultant, because your engineers say something about "recompile" and "refactor". Which you as VP don't understand, are scared of, and are not willing to spend the money on.

3) The consultant puts in a week or so to hack things together. It's much cheaper than the recompile/refactor thing, and so you as VP are a hero to your bosses.

4) Since the consultant is paid hourly, documentation seems kind of pricey. Let's skip that.

5) Lather. Rinse. Repeat.

I wish this was just Dilbert, but in quite a few companies, that's reality.

I love the last line!

I also agree that the language is probably the least of their worries. I can understand reluctance to change a system when it works perfectly, but this obviously doesn't work perfectly. Sounds like a good project for challenge.gov IMO.

I remember ~10 years ago they were trying to get the community to learn COBOL on it's own so they'd have access to cheap programmers. Isn't that how you build a business or successful organization, by exploiting the everyman for cheap labor? It worked for the ____, so I guess not since nobody fell for it.

Reply on news.ycombinator.com