- Organize the legislature(s) to pass some kind of emergency act that gives protection around PCI compliance and that sort of thing to new engineering teams

- Hire business and technical experts, fast

- Build a system on AWS that can handle massive scale and start offloading the most important business functionality to that system (things like registering for aid, fraud prevention)

- when things begin to return to normal, start processing requests through the original system, deal with problems, whatever

I know all of this is not easy. Legal and compliance stuff is tough, and I know the domain itself must not exactly be simple. But this is an emergency, and it calls for emergency measures. Trying to hack your way through an ancient code base on the fly seems like it might be doomed to failure.

Maintaining legacy code isn’t always easy, but it has a big advantage over a rewrite: it works and satisfies requirements to some non-zero percentage, whereas imaginary code built with “modern tooling” does not work or meet any requirements. COBOL and old business systems aren’t that hard to understand.

Some level of technical debt will exist in every organization. The problem is that NJ never had prioritized this work and now they have an emergency and they are looking for volunteers. They should absolutely should be paying for this work.

For the record, I wrote enterprise software in COBOL back in the late 70s and early 80s. COBOL itself is no big deal to learn or read. Working with huge volumes of data stored in proprietary binary formats (which COBOL was designed for) is not something I want to go back to -- relational databases rule the world for a good reason.

As for shunting some work to another system, imagine how you would do that with something much simpler. Suppose Excel suddenly stopped working for you with some big spreadsheets. How would you shunt that to another application? How would you do it without risking the important data? It's not a simple problem of just spinning up more servers and replacing some old data management code with MySQL or Redis.

It also doesn't pay very well.

Some days I wish an ultra virus would take out computers as we know it so we’d be forced to start again with what we know now, namely not creating these monolithic nasty monsters.

Policy should define how a system works so go read that. It’s not like you build an entire system, delete the old one, drop in the new turn it on and really really hope that it just works as intended.

But you’re right, lets just pay IBM, SAP, Oracle billions every yeah because rebuilding is too hard.

But you keep projecting on me with opinions I don’t even agree with lol. I’d hate to ever work with you.

Edit: but like k8s or not, code defined infra is a good idea - even if k8s suffers a terrible death enough detail should be documented that migration into the next big thing won’t be terribly hard. but you shouldn’t worry about that, your legacy java fat client app has so many undocumented legacy dependencies that containerisation will never be an option lol.

Not sure you could pay me enough to go back. Maybe for something ludicrous, like $3mil/yr and mutual termination at any time. I could probably put up with it for 4 months.

These places that "can't find COBOL programmers" need to stop blaming universities and start taking a harder look at themselves.

The real reason is that most companies that don't bother to move away from either physical or emulated cobol systems just do not care.

They certainly do not care enough to pay market wages.

He always told me how it was helpful to have an unsexy but useful skill set, and basically do the work that nobody else wanted to do to ensure a long career.

A janitorial business doesn't seem to be any of those things. So it seems like an area where a big company would dominate (because, say, a lot of 1000 janitorial carts is way cheaper than a lot of 10). But, no?

^I suspect it’s because janitors have access so trust of the individuals involved matters more than cost or having access to a pool of interchangeable employees.

^^There are large contractors that serve really large facilities, but that business isn’t necessary to win to be viable.

Also I think the bigger players in the space, ABM-types, aren’t interested in commercial space smaller than XX,000 sqft where my dad has been able to fit in nicely.

If you haven't done it already, please read Fred Brook's timeless classic 'The Mythic Man-Month' (1975) https://en.wikipedia.org/wiki/The_Mythical_Man-Month

Nine women can't make a baby in one month - classic wisdom that should be understood by anyone trying to organize and plan (like a governor).

And could you imagine the DPA being invoked to govern what kind of _software_ output a company produces?

I know I'm being far fetched but I'm thinking about the hypothetical of the government just saying, "Apple, you're doing government payment software now. Here's your contact. Get to work."

The bigger problem is domain expertise (or lack of), and coming up to speed on the standards and idioms used in projects like this. Requirements and documentation likely out of date.

If anyone has the actual links that include the job description, etc, I'd be curious.

https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...

8 seconds in he mentionds "Cobalt" & also at 27s

https://aws.amazon.com/blogs/apn/automated-refactoring-of-a-...

And not working with the normal build or debug tools on the mainframe it runs on.

And with a lot of extra unreadable stuff to support things COBOL does but the target language doesn't.

The biggest problem with COBOL codebases is that COBOL (at least back in the day) doesn't offer much in the way of structured programming or standard libraries. Horrifying spaghetti code with one-off local solutions for common tasks is the norm, especially on some ancient endlessly patched code.

The main problem with a direct conversion is COBOL has database operations in the language, mapping data directly to variables (records). All modern languages you might translate COBOL to use libraries to perform database operations, and may not even have an off-the-shelf implementation of the pre-relational data structures COBOL was originally designed to work with.

Ignorance of the details of the NJ system is the great challenge. Its likely a huge legacy system with all of the attendant warts, histories, strange choices, and odd limitations that come with that. Given that these systems are built up through years of teams of people that come and go - it will likely take a long time to address the real issues.

> Ignorance of the details of the NJ system is the great challenge.

This seems very plausible. But on this analysis, what's the point of trying to hire "COBOL programmers"? We've just stipulated that the COBOL is easy. Onboarding an experienced COBOL programmer is only a trivial savings over onboarding someone who's never heard of COBOL; they'll both have to learn the system -- but the pool of experienced COBOL programmers is much smaller than the pool of "everyone".

Would you mind sharing a quick summary if you've synthesized the position?