Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

New Jersey needs COBOL programmers for their unemployment claims system

twitter.com

Post reply on HN
Print view View original

21–30 of 309 posts

Re: New Jersey needs COBOL programmers for their unemployment claims system

#21

Post by CWuestefeld »

This is all second-hand, etc., but from what I've heard, NJ's IT systems are a mess across the board.

The most shocking story was about their system for tracking Medicaid patients. Their system had a fixed-width field for the patient's ID, and they ran out of identifiers - so they just started to recycle them again from the beginning. This problem was multiplied by the fact that, to say money, they didn't have backups of the original, clean data before the recycling. Thus it became pretty much impossible to understand what benefits had been afforded (or not) to whom.

Governmental budgeting seems biased strongly in favor of labor expenses, especially those with seniority, to the detriment of the maintenance of capital assets. This is pretty much a recipe for technological debt.

Re: New Jersey needs COBOL programmers for their unemployment claims system

#22

Post by tyingq »

vikramkr wrote: post #4

How hard is cobol to pick up and learn at the level needed to contribute? I'm sure there are many no longer employed programmers in the tri state area that might be able to help

The ecosystem would be the harder part. It's either a 360 mainframe, AS/400, HP MPE, etc. The editors, compilers, runtime, batch schedulers, etc, are all different.

Re: New Jersey needs COBOL programmers for their unemployment claims system

#23

Post by thaumaturgy »

gecko wrote: post #20
NikolaNovak wrote: post #12

Earlier quoted context omitted.

Programming a net new isolated Cobol may not be difficult for experienced programmer. Difficulty (and/or downright hate, for many;) lies in 1. Ecosystem - obscure libraries rules and os that don't jive with posix-like mindset 2. Legacy code - having to dig into a ginormous monolithic program and figure out what some obscure pieces of code do, untouched and undocumented by anybody in your team, with ridiculous interde…

Is there any way to learn the ecosystem? Last time I looked, you couldn’t just spin up z/OS in VMware and start hacking, which made it hard for me to figure out how I’d actually learn.

Intern or junior-level in a COBOL environment, unfortunately. Like others are saying, the problem with COBOL isn't (just) the language itself, it's all of the decades of very delicate cruft that has grown up around it. COBOL-the-language is absurdly simple to the point of being a little brain-damaged; but you have to be able to work in an environment where there's really close coupling between COBOL and its host operating system, and where minor code changes can have unintended consequences in seemingly unrelated applications, and the database isn't transactional, and there's no version control, and...

Re: New Jersey needs COBOL programmers for their unemployment claims system

#24

Post by nodesocket »

commandlinefan wrote: post #7

Yet I’m sure they’re offering $60K/year.

I whole heartedly agree. The problem with government tech positions is they are not even competitive. Instead of hiring three mediocre or less than mediocre engineers at $60k, why not hire an amazing $150k - $180k engineer? I’m pretty sure they have ceilings on positions just so people don’t get outraged at government salaries, but incidents and times like these prove government needs to be competitive with private business to attract talent. Especially in national security and healthcare roles.

Re: New Jersey needs COBOL programmers for their unemployment claims system

#25

Post by syshum »

Spooky23 wrote: post #19
c3534l wrote: post #15

The point at which the government should have rewritten their COBOL systems into a language that would have a talent pool to draw from was at least 30 years ago.

Easier said than done. UI is mostly federally funded so they need to coordinate with them, and the complexity of the business rules and minimal funding during good times makes it a difficult task. Also these systems generally work well, and it’s hard to fix things that aren’t broken. They just cannot handle the never before seen volume — it’s unlikely that a more modern enterprise system would either.

>>it’s unlikely that a more modern enterprise system would either.

sorry but that is just false. a Properly designed modern system would handle horizontal scaling just fine.

Granted the government would likely pay a billion dollars to have a screwed up system developed by on of the "big guys" that has the same problems as they current system, most likely because it would be designed by committee and not by engineers.

However to say that modern systems could not handle this kind of problem is just wrong. There are all kinds of ways to handle a sudden increase in load.

Re: New Jersey needs COBOL programmers for their unemployment claims system

#26

Post by dehrmann »

_delirium wrote: post #16
c3534l wrote: post #15

The point at which the government should have rewritten their COBOL systems into a language that would have a talent pool to draw from was at least 30 years ago.

There's a claim in one of the reply threads that they contracted HP to build a replacement years ago, but the project didn't succeed: https://twitter.com/tradel/status/1246526465207869440

This feels like government thinking around infrastructure or military hardware where you open up bids and accept the lowest offer.

While there are problems with lowest-bidder-win, the real issue here is that systems like this are more living and breathing than one-off; you need a teams that tend to them, not bringing in a contractor.

Re: New Jersey needs COBOL programmers for their unemployment claims system

#27

Post by tantalor »

vaidhy wrote: post #13

I used to work on mainframe COBOL during the Y2K times. While the language is easy to pick up and the OS specific things are not too hard, the style of programming can lead to issues. Typically, shared data structures are often stored in separate files called copybooks and they can be hard to track down. Most of the code is not in any source control repositories which means no one knows which is the actual deployed v…

That's not an issue with "style of programming", it's just complete disregard of software engineering basics.

Re: New Jersey needs COBOL programmers for their unemployment claims system

#28

Post by bitwize »

ravenstine wrote: post #17
Analemma_ wrote: post #9

Earlier quoted context omitted.

The thing about old COBOL systems is, the language isn't the problem. Snark aside, it isn't that bad. The major issue is the code written in it. Remember, a lot of COBOL code comes from a time before a lot of programming best practices were discovered. Structured programming-- as in, actually having function calls instead of just GOTO statements everywhere-- was a novel hoity-toity concept when COBOL first existed. R…

That, and I don't imagine there's any tests written for a lot of these systems. :(

There are plenty of tests written for them.

They are just manual tests written up on literal, actual TPS reports (TPS = Test Procedure Specification) to be executed by humans.

Re: New Jersey needs COBOL programmers for their unemployment claims system

#30

Post by Lammy »

dehrmann wrote: post #26
_delirium wrote: post #16

Earlier quoted context omitted.

There's a claim in one of the reply threads that they contracted HP to build a replacement years ago, but the project didn't succeed: https://twitter.com/tradel/status/1246526465207869440

This feels like government thinking around infrastructure or military hardware where you open up bids and accept the lowest offer. While there are problems with lowest-bidder-win, the real issue here is that systems like this are more living and breathing than one-off; you need a teams that tend to them, not bringing in a contractor.

The linked Twitter thread includes replies from someone who worked on the intended-replacement system indicating that “in the field” data entry accuracy was one of the biggest problems and not something that could be easily solved in code.
Post reply on HN