
COBOL programmers answer call - furcyd
https://spectrum.ieee.org/tech-talk/computing/software/cobol-programmers-answer-call-unemployment-benefits-systems
======
triska
COBOL can be a real pleasure to use.

For instance, it allows programmers to quickly create user interfaces by
declaratively describing them, in a so called SCREEN SECTION.

The resulting interfaces are very efficient for text entry, and allow users to
quickly get a lot of work done. The interaction is so much more efficient than
what we are used to with current technologies that it can barely be described
or thought about in today's terms.

Regarding the underlying theme of legacy systems, here is an interesting
presentation by Jonathan Blow, citing various examples of earlier
civilizations losing access to technologies they once had:

[https://www.youtube.com/watch?v=pW-
SOdj4Kkk](https://www.youtube.com/watch?v=pW-SOdj4Kkk)

I think in terms of user interfaces, we are on a downward path in several
important ways, and I highly recommend checking out earlier technologies that
were in many ways an improvement over what we are working with today.

~~~
gumby
> For instance, it allows programmers to quickly create user interfaces by
> declaratively describing them, in a so called SCREEN SECTION.

By the way if it seems odd to have I/O like this in your language:* this
reflects the architecture of mainframes; because the CPU was so important, I/O
was managed by external devices (typically themselves a cabinet of
electronics, at a time when the CPU took up two or three cabinets itself).
You'd write essentially a small program describing what IO you wanted and then
let the IO channel controller be busy dealing with minutiae like dealing with
the tape drive motor or input from terminals.

So the language would set up data to be slapped to a terminal (this would have
been a decade or more after COBOL was written, once terminals with screens
were available), which the channel controller would send to the appropriate
terminal. It would then deal with input and once all was ready, tell the CPU
that it had a bunch of input ready.

Terminals like the 3270 were even half duplex so would process the input and
then send it off as a block, to make the channel controllers more efficient!

In the ARPAnet of the 1970s, the ITS PDP-10s and -20s took this further with a
protocol called SUPDUP (super duper) which allowed this kind of processing to
be done on a remote machine when logging in over the net (as we would do today
with ssh). So you could log into a remote machine and run EMACS, and while you
were editing a remote file with a remote editor all the screen updating would
be done by your local computer! Even the CADR lisp machines supported this
protocol!

* At the time _not_ doing IO through the language itself was considered oddball. I seem to recall a line in the original K&R where they described C's I/O and made an aside, '("What, I have to call a function to do I/O?")'

~~~
rbanffy
It's quite clever, actually. Offloading specialized work to autonomous
subsystems allows the CPU to run your code better than it would if the CPU
also had to deal with reading from disk or assembling packets for the network.
A modern mainframe has tons of such systems and that's what allows them to
process volumes of transactions that PC-based servers of the same price range
can't.

In fact, our PCs are like that because they had to be cheap and the cheapest
way is to burden the CPU with all work.

~~~
gumby
Actually I’d disagree a bit with your last sentence. Handling io interrupts in
the kernel was a property of cheap machines like minicomputers that you could
buy for a few hundred $k or less. You typically couldn’t afford extra channel
controllers on cheap machines like that. Hence Unix’s I/O architecture was
driven by the constraints of the PDP-7. Multics has a standard io controller
architecture.

PCs of course had the same issue — down to the cpu controlling the speed of
disk rotation! But a modern PC has an I/O system more complex than the
mainframes of old, with network interfaces that do checksum processing,
handling retransmission and packet reassembly etc, just DMAing the result.
Disk drives, whether spinning or SSD have a simple, block interface unrelated
to what the storage device is doing, etc. I think this is all as it should be,
though I personally consider the Unix IO model grossly antiquated.

~~~
DonHopkins
If /dev/zero is an infinite source of zeros, then why doesn't the minor device
number specify which byte to use? Then you could make character special file
/dev/seven that was an infinite source of beeps! There have been so many times
I needed that.

~~~
rbanffy
Great idea! Also, for when you need some paper, you can pipe /dev/twelve to
your printer.

We should propose a kernel patch for this next April.

Extra credit if we get it rolled into POSIX.

------
aazaa
It's not so clear that COBOL is to blame:

> COBOL “remains one of the fastest programming languages,” said John
> Zeanchock, associate professor of computer and information systems at Robert
> Morris University. “We get calls from big companies in Pittsburgh, like Bank
> of New York Mellon and PNC Bank, looking for COBOL programmers. The
> limitations of COBOL itself are probably not the problem with New Jersey’s
> system,” Zeanchock said, adding that a single mainframe computer could
> probably handle the processing needed for an individual state’s UI
> unemployment insurance system, even if the number of applications increased
> tenfold.

[https://slate.com/technology/2020/04/new-jersey-
unemployment...](https://slate.com/technology/2020/04/new-jersey-unemployment-
cobol-coronavirus.html)

The article goes on to note:

> When it comes to our broken social safety net, COBOL isn’t really the bad
> guy: blame Congress for underfunding the programs, and states for failing to
> make up the gaps.

And later:

> “We’ve known for a long time that even a much smaller crisis would lead to
> daunting challenges,” said Dutta-Gupta. He points out that during the Great
> Recession, state unemployment agencies were so understaffed that their
> agency heads spent shifts answering applicant phone calls. Even if states
> weren’t getting federal funding, they still could have paid for better
> technology with their own tax revenue. According to reporting by the Tampa
> Bay Times, former Florida Gov. Rick Scott and current Gov. Ron DeSantis
> ignored repeated warnings that the state’s website barely functioned.

This looks a lot less like a computer problem and more of a process and
institution problem made much worse by chronic underfunding and understaffing.

~~~
lotsofpulp
> This looks a lot less like a computer problem and more of a process and
> institution problem made much worse by chronic underfunding and
> understaffing.

It’s a political issue. Some states are broke (e.g. NJ), and some are hell
bent on not helping others in society so they handicap social welfare systems
(e.g. FL). Real solution won’t come from a few COBOL programmers, it will have
to be voters voting in people who will address the issues.

~~~
pas
How broke is NJ? What could they do? Why aren't they?

~~~
lotsofpulp
Extremely broke.

[https://www.truthinaccounting.org/news/detail/financial-
stat...](https://www.truthinaccounting.org/news/detail/financial-state-of-the-
states-2019)

Other than defaulting on their debt, they can’t do any thing about it as the
money was spent decades ago in the form of defined benefit pension payments in
the future. If all the recipients of those future defined benefit pension
payments died, then that would also lower their debt.

~~~
pas
Hm, so currently they just "service the debt", they can issue bonds and just
pay out over 50+ years. I don't see why they don't plan for the long term with
this.

They are relatively a prosperous state. (Good GDP per capita, good income
after taxes -
[https://upload.wikimedia.org/wikipedia/commons/9/9f/Median_h...](https://upload.wikimedia.org/wikipedia/commons/9/9f/Median_household_income_and_taxes.png)
, though life is accordingly expensive 34th overally affordability -
[https://www.usnews.com/news/best-
states/rankings/opportunity...](https://www.usnews.com/news/best-
states/rankings/opportunity/affordability) \- better than Florida, Washington,
NY, CA, etc. 2017 "PPP" is 112% of national average, close to NY's 115% and
CA's 114%.)

Though they should just ship pensioners to a cheap-to-live state, eg Florida
or Pennsylvania.

Okay, okay, armchair policy recommendations are always very nuanced and great
(not to mention useful), especially on random internet forums! But the level
of dysfunction due to braindead leadership is always surprising.

------
kristopolous
I asked a few friends about the New Jersey call. They (2 of them, both retired
and over 70) claimed there's no work to be done and it's actually an
incompetently administered administration with human problems who are
scapegoating the technology. Also supposedly the New Jersey govt sacked their
team and then was trying to contract out the work at $50/hr. Now they are
offering $0/hr. And the solution isn't in software, or so they claimed.

This assessment was after both signed up to volunteer to do the work and saw
it was a human process failing and not a software issue. People tend to point
to the parts most mysterious to them when things start to fail - a zSeries
frame is in actual reality, a very important big black mystery box that
officials with access to microphones are not allowed to touch - perfect.

Don't let this discourage you though, their problems are still very real.

~~~
JPKab
How many folks on HN have witnessed this same very thing within large mega-
corps and government agencies? I've seen it a LOT.

The big bummer is that the crisis almost requires enabling behavior here, in
the sense that if there are things wrong with said COBOL system, it's the
fault of the NJ gov't for not fixing it a long time ago. People should rescue
this for the sake of the unemployed, but can we please fire people for this?

This isn't a red state: They collect plenty of revenue. So IF IT IS COBOL
SYSTEM, and not just bureaucrats, it's still NJ's fault.

As Bezos said recently regarding the Seattle city gov't:

They don't have a revenue problem. They have a spending efficiency problem.

~~~
alharith
> This isn't a red state: They collect plenty of revenue.

Part of this revenue collection (tax policy) is why corps are moving en masse,
the recent largest example is Honeywell's relocation to Charlotte. NJ's latest
tax hike has actually caused them a net loss in revenue.

~~~
pas
How it affected their expenses? A big corp leaving lessens services
utilization which might help if NJ was paying a hefty premium for over-using
their infrastructure.

~~~
alharith
A good theory but doesn't apply here, but I did leave out a key piece of info:
the largest drop has actually been in income tax ala large hedge fund managers
who have fled the state. Carolina Panthers owner and billionaire David Tepper
is one recent-ish high profile example, but there are many others. Corps like
Honeywell aren't an infrequent sight either. New Jersey's revenue has fallen
YoY since the loss of Tepper et all.

The insane part of me here is NJ politicians keep clamoring to raise taxes
more. It's almost as if they heard De Blasio's campaign slogan and thought it
was a great idea.

------
codenesium
I worked in COBOL at an internship and this was around 2012. This system runs
over 1000 court systems in the U.S. It's graphical too and sort of looks like
vb6 on the frontend. It was a nightmare to work in even though the team was
disciplined and took care of the codebase. You can't write 10k line programs
with all global variables and have something that's nice to work on.

~~~
m463
I remember working on a super-old-legacy Fortran program that had 6-character
significance for the variable names.

I vaguely remember they had different namespaces using common blocks.

~~~
int_19h
This might not be all that old! Early ISO C standard (1990) had the same
6-significant-character limitation for identifiers exported across translation
units. So far as I know, this quirk is there because early C implementations
reused pre-existing Fortran 77 linkers, many of which still had that limit at
the time.

------
xvilka
And at the same time, Gentoo maintainers are reluctant[1][2][3] to update the
shipped version of GnuCOBOL. Similar to Fedora/RHEL[4]. And it's far from dead
- GnuCOBOL is actively developed[5] and preparing[6] an upcoming release this
year.

[1] [https://bugs.gentoo.org/641888](https://bugs.gentoo.org/641888) (reported
3 years ago!)

[2] [https://bugs.gentoo.org/685960](https://bugs.gentoo.org/685960) (reported
1 year ago!)

[3]
[https://github.com/gentoo/gentoo/pull/12067](https://github.com/gentoo/gentoo/pull/12067)

[4]
[https://bugzilla.redhat.com/show_bug.cgi?id=1714241](https://bugzilla.redhat.com/show_bug.cgi?id=1714241)

[5] [https://sourceforge.net/p/open-
cobol/code/commit_browser](https://sourceforge.net/p/open-
cobol/code/commit_browser)

[6] [https://sourceforge.net/p/open-
cobol/discussion/cobol/thread...](https://sourceforge.net/p/open-
cobol/discussion/cobol/thread/7dc2941f/?page=4)

~~~
tasubotadas
Ah. Gentoo. That brings up memories - I've used it as my main OS for ~3yrs.
Updating OpenOffice with 4h compilation times used to be fun :).

It's great to see that they are alive and kicking.

------
dang
Robert Glass wrote a series of articles in the 80s and 90s defending COBOL. I
once wrote him (the old fashioned way, with an enclosed check!) to get back
issues of his old printed newsletter because I wanted to hear what he had to
say about it. Those don't appear to be online, but here's an article he wrote
in 1997 for CACM:

[https://www.thefreelibrary.com/Cobol+-+a+contradiction+and+a...](https://www.thefreelibrary.com/Cobol+-+a+contradiction+and+an+enigma.-a020378493)

~~~
IggleSniggle
That was honestly a great read. Would love to read the same article but
rewritten for today's context. Thanks for sharing it.

~~~
dang
Glass is probably best known now for his book "Facts and Fallacies of Software
Engineering", which is a pretty good entry in a pretty lame genre, which is
the attempt to draw meaningful conclusions from the research literature on
software engineering. The main lesson of the book is how poor the studies are,
but it's still worth reading for his own wisdom.

------
nonamenoslogan
I work in County IT in a medium large county in my state, about 110K
residents. We just finished a migration from COBOL on HP3000 to SQL+ColdFusion
and some ASPX. COBOL is infinitely faster at computation on PARisc than SQL is
on Intel; our HP3000 is a 120MHz with 500mb of ram and our Intel stuff is VM
on ESXi. Running a tax roll on COBOL for 45K parcels takes a fifth of the time
on the HP despite the massive hardware differences!

~~~
PaulWaldman
Why was "SQL+ColdFusion and some ASPX" selected as the replacement stack?

~~~
nonamenoslogan
Two systems, one for Tax/Assessment which was provided by the state is SQL and
ASPX and the other which is used for historical inquiry and document
generation which is in-house code in SQL and Coldfusion.

The ASPX taxing/assessment system is the slow one in comparison when it comes
to calculating. The ColdFusion system is not as hindered but its used for
making letters and reports, exporting layers to GIS, and generally replacing
COBOL-screens for information retrieval.

Is/are there better solutions, yes, but I was giving an example rather than
critiquing the County’s choice of software that happened well before I came
along.

------
themodelplumber
We should have a celebratory COBOL-thon this weekend. Everyone write a minimal
COBOL app. Just for fun.

Not sure if the COBOL bridge for Node is allowed. :-)

Resources:

[https://opensource.com/life/15/10/open-source-cobol-
developm...](https://opensource.com/life/15/10/open-source-cobol-development)

[https://archive.org/search.php?query=COBOL%20programming](https://archive.org/search.php?query=COBOL%20programming)

~~~
chx
And what about [https://github.com/azac/cobol-on-
wheelchair](https://github.com/azac/cobol-on-wheelchair) ?

    
    
           display
               "content-type: text/html"
               newline
           end-display.
    

Most of your webapp is already done :D

------
avgDev
I am wondering if my old professor answered the call. He used to work in the
banking industry, is very outspoken against Capitalism and got fired for
wearing jeans.

I have been working on a project and have some experience with DB2/AS400, it
is not as old as COBOL. It is not very fun or exciting and stackoverflow lacks
much information, a lot of trial and error.

I can't believe how widespread these old systems are. I am surprised nobody
has decided to update them, I mean when these old developers die or
retire......they will have a hard time migrating to a newer systems.

Bonus: I HATE IBM, .Net Core provider to access database? That is a few $$.
Crappy documentation? Check. Deleted code examples I had bookmarked? Check.
IBM forum questions answered in private messages, so nobody else can use the
information and the question needs to be asked hundreds of times? Check.

IBM is so upside down.

~~~
artificial
I thought IBM handles this by making VMs so old things can run on the new(er)
things? Isn't it turtles all the way down? I worked for a company that
specialized in distribution and circulation software for all the big papers at
one point in time or another and it was all COBOL with some of the code bases
as old as I was (a handful of engineers remained which laid down a few of them
were still on staff, pretty cool resources since they've solved pretty much
everything). I bagged a bunch of AS400 operating manuals which were on their
way to the trash. I've got one on my shelf I wish I could share with you.
Anyway to complete the anecdote one of the younger engineers found their way
to greener pastures by creating a screen scraper of sorts for the AS400 to
expose it to another API. My mind was blown at the time but it makes sense
since these were the webforms of their day.

~~~
avgDev
In our case we have an IBM iSeries box, AS400 uses DB2 as its database. I am
writing an application that communicates with DB2, and I perform a lot of
queries directly on the database. We also do have a book on AS400 but most
development is done by our old school dev. There is plans to migrate to a
newer system but the cost is quite expensive.

I mostly work in .Net MVC/Core. However, connecting to db, obtaining licenses,
etc have been a real pain.

------
jerhewet
I coded COBOL and RPGII programs back in the late 70's, and I'd flip burgers
before writing another line.

~~~
elliekelly
Oddly enough I suspect you’d have a much harder time getting hired for a
burger flipping gig at the moment. What a strange time.

~~~
DoofusOfDeath
Maybe, maybe not.

If we make these (very questionable) assumptions:

\- Most qualified mainframe COBOL programmers are in an age bracket for which
COVID-19 is very dangerous,

\- and most COBOL shops are reluctant to allow all-remote teams,

then it might be harder to fill those jobs than it is to hire risk-tolerant /
risk-ignorant young adults to flip burgers.

~~~
wpietri
For what it's worth, my dad was doing remote COBOL in the early 1980s, so the
technology is available.

------
Animats
COBOL was the first language to take data format seriously, with "records" and
a "data division". To some extent, it still is. Look at the gyrations people
go through to get Java or Python to talk to an SQL database. The programming
language itself has no clue about database layout.

~~~
ptx
Python takes care of the records pretty well with named tuples (and since it's
dynamically typed, not knowing the fields until runtime is expected). It
doesn't have anything for the query part through, like C# does with LINQ - are
you saying that COCOL does? What does this knowledge of database layout look
like in COBOL?

~~~
jquast
Since python 3.7, dataclass is probably preferred over namedtuple, which is
typed, [https://realpython.com/python-data-
classes/](https://realpython.com/python-data-classes/)

~~~
faizshah
Dataclass is not immutable, for some cases typing.namedtuple should be
preferred over dataclass if typing is needed. Deep dive here:
[https://stackoverflow.com/questions/51671699/data-classes-
vs...](https://stackoverflow.com/questions/51671699/data-classes-vs-typing-
namedtuple-primary-use-cases)

~~~
tasubotadas
That's not really true - you can set frozen=True and you will get an immutable
version of the class.

------
zelly
If you want me to work on it for free, a mechanism already exists for this.
It's called open source. Put the codebase on Github or wherever and I'll
contribute.

~~~
rbanffy
The odds that their actual problem is COBOL code and not mismanagement are
vanishingly small.

That said, if it's paid with public funds, it _should_ be open source.

------
hanoz
What's the equivalent technology of today to get in on, in order to get some
of this kind of money for old rope action in our retirement?

~~~
icedchai
C and Java are going to be around forever.

------
yingw787
I wonder if I'm personally addicted to easiness. I stand on the shoulders of
giants and I forget just how nice it is to dig my toes into the soil.

I have a full set of Donald Knuth's "The Art of Computer Programming" sitting
on my shelf, unopened after two years. Maybe it is time to rifle through it
and learn how to program like the pioneers did in the old days.

~~~
Alex63
No criticism of TACP intended, but I don't think you would find it very
helpful in learning "how to program like the pioneers did in the old days." I
don't remember too many of my older colleagues in the 1980s having copies of
Knuth. It was something you might encounter among computer scientists, but not
day-to-day working programmers. We rarely thought about algorithms in that way
when we were building business systems. If we did need an algorithm (maybe to
sort some customer records that were stored on tape) we would dig out the IBM
or DEC binders and look up the system call that we were supposed to use.

I suspect that programmers who have grown up in the era of the PC would be
surprised at how much the vendors supplied. The IBM mainframes came with huge
libraries of software and documentation. I remember being given a UNIX box for
a project at the telco where I worked, and being a little surprised at how
little was included compared to the IBM or DEC machines of the day.

There certainly were some good programmers around, but a lot of "development"
consisted of taking a copy of some existing COBOL program and tweaking a few
things to create a new report. Out of two or three years of working in COBOL,
I don't think I ever wrote a program completely from scratch. As a creative
outlet, it was much more interesting to work in C and try to figure out how
the guys at Bell Labs were doing things. Those are the shoulders that many of
us stand on today.

------
hestefisk
Can any of you seasoned COBOL programmers in here please point to the best
learning resources for this? I would love to learn it but I don’t have any old
IBM mainframes lying around.

~~~
rbanffy
GNU COBOL runs on pretty much anything. You can play with it right now. No
need for a mainframe. In fact, a lot of COBOL code running these days is not
running on mainframes.

Mainframes are not big Unix boxes. Their OSs were evolving for decades before
Unix booted for the first time and are very different from anything most
people have direct experience with. You can boot up a legal copy of MVS 3.8j
(or an illegal one of its modern descendant z/OS) but expect a learning curve.
You can also get something similar from Unisys for their Clearpath machines.

~~~
Aloha
The thing that struck me from coming from a unix background was that the
entire OS was record aware, all the native tools, everything. Stuff that is
just hard in unix is trivial in z/OS

~~~
Taniwha
Having grown up in the older 'record aware' systems unix bytestreams were a
wonderful breath of fresh air (this was back in v6/v7) - I guess perspective
is everything

~~~
rbanffy
Being record aware comes from the punched cards that were the most popular way
to keep data when they started evolving. They were born before ASCII (they use
EBCDIC and, while ASCII was supported in one early IBM 360 model, it was
dropped almost immediately)

Unix was born after magnetic storage, both disk and tape, were common. A file
looks a lot like a tape.

~~~
Aloha
System/360 was supposed to be ASCII from the get go, the architecture supports
it (the RCA Spectra 70 series which was a System/360 architecture system was
ASCII).

All System/360 descendants support ASCII, the issue they ran into early in the
System/360 program was accessories, IBM had lots of EBCDIC I/O devices, and
developing a line of ASCII I/O devices would have delayed introduction of the
line by a period of time.

~~~
rbanffy
The USASCII-8 mode bit in the program status word existed in all 360's (sorry
about that) but was removed in the 370.

------
meerita
My father programmed in COBOL, but he never talked me about this. Anyone mind
to share his experience? What would be to do this today? is it hard to learn?

~~~
artificial
Evidently it's a faux pas to ask about :P akin to asking veterans about war
stories. You may get a kick out of this:
[http://www.coboloncogs.org/HOME.HTM](http://www.coboloncogs.org/HOME.HTM)

~~~
dylan604
The first rule of COBOL programming is you don't talk about COBOL programming.

The second rule of COBOL programming is...

------
bobbydreamer
“Cobalt” skills. Really. Learning just COBOL is not enough, you will have to
learn ISPF, SDSF, JMR, JCL, Db2, CICS, CA7, ENDEVOR.

Think about it 40yr old system still running. Amazing right. Pick any language
today, write a program little bit enterprise level, will it run for another
40yrs without any major changes.

------
neonate
[https://archive.md/ns6F8](https://archive.md/ns6F8)

------
xyst
I would answer the call for 250K, up front.

~~~
snicker7
In NJ, they are asking for volunteers.

And they wonder how it got this bad.

~~~
xyst
It's like an unpaid internship, smh

years of "it already works, dont fuck with it" policy and tech illiterate
politicians.

------
RickJWagner
This seems like the makings of a movie. Along the lines of "Space Cowboys" or
maybe another "Grumpy Old Men".

------
AzzieElbab
What exactly are these Cobol programmers supposed to do? Process punch cards
manually?

------
api
Was there a COBOL search light bat signal? Because there should be.

------
throaway1990
COBOL programmers rise!

~~~
avgDev
Back from the dead!

~~~
DoofusOfDeath
I saw the best minds of my generation destroyed by COBOL copybooks...

------
newprint
Just put the entire COBOL source code on the github and let us rework it in
the Java or C# and be done with this abomination.

~~~
DoofusOfDeath
Verifying the equivalence of two large programs can be very difficult.
Developers often underestimate the effort needed to achieve a correct rewrite.

~~~
aNoob7000
Exactly and figuring out all the logic with code that's been refined and built
out of 20-30 years.

Any developer saying, "Hey, go and rewrite the code" underestimate all the
edge cases that end up all over the place in the application.

------
cable2600
Someone invent a COBOL to Python converter to get rid of these old dinosaurs
IBM Mainframes.

~~~
lukevp
Mainframes aren’t some old crusty thing that’s about to die from all the bugs
stuck in the fans or something. We have a cobol system and it runs on modern
IBM hardware. Besides, almost everything is virtualized now anyway.

The mainframes aren’t the problem, and doing a code conversion of COBOL is not
trivial. Their data types are completely at odds to normal data types in
modern languages (for example, you can specify a string that is always exactly
30 ascii characters long, the 4th character must be a numeric, the 18th must
be ascii but not numeric, the 22nd through 30th must be alphanumeric. All with
a native datatype. And that’s just the scalar types, Cobol data types natively
support recurrences and redefines and heirarchies. And the language has like
400 keywords.) You end up having to wrap every single line of code in
compatibility layers upon compatibility layers, and then it doesn’t even look
like python, it just looks like a crappier version of Cobol, to make it
function identically.

It’s much easier (though more time consuming) to read the code and determine
the business rules being enforced and reimplement them in a modern language.

I have worked with a lot of Cobol translators and their output is worse than
the original code by far. With a lot less confidence and experience with
maintaining it.

