
The governor of NJ went live on TV to request COBOL programmers - saadalem
COBOL is operating for a number of practical reasons in the US.<p>Universities stopped training because it was not—glamorous.<p>Now NJ needs 100s of programmers—TODAY.
======
steven77723
Discussed at:
[https://news.ycombinator.com/item?id=22782097](https://news.ycombinator.com/item?id=22782097)

------
okareaman
link:
[https://www.youtube.com/watch?v=nlJqlWSPJeI](https://www.youtube.com/watch?v=nlJqlWSPJeI)

~~~
choward
Cobalt? Haha. I don't think anyone on earth has experience in that. It better
pay well.

~~~
xxpor
Some child miners in DRC might disagree :(

------
ellius
I'm a younger engineer, so I say this with a degree of humility, but is trying
to modify these monstrous legacy systems on the fly during a worldwide
catastrophe really the most responsible or intelligent solution? Is there no
way to authorize some kind of emergency system built with modern tooling to
offload the system burden and then process it later through the system of
record? If I were trying to deal with this problem, my approach would be the
following:

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

~~~
gregjor
I think you underestimate the scope and scale of systems like this. And maybe
overestimate the success rate of rewrites, made worse when the developers have
no domain experience and a rushed schedule. Under the best conditions rewrites
fail more often than not.

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.

~~~
ellius
I wasn't imagining a full rewrite, more like a "holding area" that could defer
some of the load. Again I may be totally wrong about this—I have never written
a COBOL system, and if there is some plausible way to make it effective for
this problem in a reasonable timeframe, then I understand why that would make
sense. I understand all of your reasoning and agree with it in general. I know
rewrites are very expensive and often ineffective. I'm just skeptical that the
system can be modified quickly to deal with this new load. But again I am not
an expert and could be totally wrong, and I'm open to being convinced.

~~~
gregjor
The big problems likely have very little to do with COBOL, which is just
another programming language, not an alien artifact. The problem is legacy
systems like this that pre-date relational databases (mid-1980s) have huge
volumes of data stored in application-specific formats that modern languages
don't have drop-in packages or libraries for. The data is always a bigger
problem than the code in large systems.

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.

------
Blackthorn
> Universities stopped training because it was not—glamorous.

It also doesn't pay very well.

~~~
Bnshsysjab
If it’s anything like legacy public service code in my country it’s not just
that, it’s also dealing with terrible organisational culture, d-grade devs,
c-grade contractors and corrupt management that let it get that way (as
millions are dumped on the contractors, as it turns out).

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.

~~~
grogenaut
Cool we'd have a bunch of new monsters based on a super old version of nodejs
instead.

~~~
Bnshsysjab
I’m not saying you can’t write a monster in node (nor would I recommend
writing complex apps in it) but modern systems are somewhat less monolithic,
if a component is garbage rebuild it, run unit/integration tests and push to
business to verify. You can’t do that when your application is such a black
box even the devs don’t truly know how it works, which often seems to be the
case with legacy cobol.

~~~
grogenaut
Cool you missed "actually understand the legacy system" and went right to the
grand rewrite into microservices. If you can't be bothered to understand one
service from 30 years ago, how is someone 30 years from now going to
understand your 45 service masterpiece let alone run the out of date kube
cluster you deployed it to.

~~~
Bnshsysjab
You’re putting words into my mouth I _never_ mentioned microservices and think
that largely they’re a mistake (except SSO). I also never mentioned node. At a
glance I assume C# or Java would be the best fit but I’m not a system
architect so my POV is probably mute.

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.

------
sharkweek
My dad, when I was in elementary school, started a small commercial janitorial
business that he runs to this day, even though he’s mostly retired.

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.

~~~
papeda
Curious, how does a small commercial janitorial business survive for so long?
My naive understanding as a non-business-owner is that small entities can
survive or even do well if they offer a product that's hard or not worth it
for big entities to replicate at scale. Some examples might be art, or a nice
feeling of "buying local" from people you know and like, or a niche product
whose market is just not big enough for giants to bother with.

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?

~~~
1123581321
I don’t know why^, but the largest janitorial/cleaning companies that serve
ordinary businesses^^ are franchise companies. Local independents just have to
compete against branded local companies.

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

------
blululu
>>needs 100's of programmers - TODAY

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

------
Waterluvian
Generally speaking how long would it take to mobilize any competent senior
software developer as a COBOL developer?

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

~~~
gregjor
I learned COBOL from the (then) standard text by McCracken back in the early
1980s. It’s not hard, a week or two for someone with programming experience.

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.

------
27182818284
In the YouTube clip, the URL [http://covid19.nj.gov/](http://covid19.nj.gov/)
but there is still as of yet no mention of COBOL as far as I can see.

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

~~~
macintux
I don’t have a direct link for you, but this topic has popped up several times
in the past few days and you might find something more substantive.

[https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...](https://hn.algolia.com/?dateRange=all&page=0&prefix=false&query=cobol&sort=byDate&type=story)

------
Tepix
URL? What does he need them for?

------
amelius
How hard would it be to automatically convert that COBOL to e.g. C++ or Rust?
I suspect not that hard, since COBOL does not even have a heap afaik.

~~~
retrac
It can be automatically translated. But then all you've done is convert a
bunch of IF A < B THEN GO TO STEPTWO into if (a < b) { goto steptwo; }

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.

~~~
gregjor
Not true, COBOL has as much structure as any other language, if the
programmers wrote their code that way.

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.

------
tomohawk
Must not be willing to pay enough or be hard to work with. At the right price,
100 people should not be hard to find. Of course, they probably would not be
in this position if they were willing to put money into the system or keep
people on retainer at least.

~~~
dreary_dugong
I recommend taking a look at the other discussions linked. Unfortunately the
situation is more nuanced then "just pay them more."

~~~
renewiltord
I tried reading the other threads but they are not very information-dense.
It's mostly people arguing about whether governments are good employers.

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

