Re: Rewriting SSA. Is This A Chance For GNU/Linux?

On 4/6/25 11:33 PM, Rich wrote:

c186282 <c186282@nnada.net> wrote:

Ummm ... given option ... I'd rewrite SSA/IRS using
one of the BSDs (maybe a commercial version) as the

 The problem that will be encountered in "rewriting" SSA or IRS is not
the software.

   Ummmmm ... kinda. It HAS to work, kinda flawlessly
   from the start. The political fallout from errors
   is TOO much.

The problem area is the 'rule book' defining what the software is to
do.  The first problem is, there is no single "rule book" with which to
refer.  It is all spread over thousands of statutes that themselves
have been patched plural (millions?) of times throughout the years both
SSA and IRS have been around.  If one could collect all the 'rules' of
what should happen given specific inputs together into a single 'rule
book' and print it out the result would likely be a 6 foot high stack
of double sided US letter sheets of paper.

   "Federal laws/regs" have been tweaked and re-tweaked
   by politicians since the inception. They respond to
   'pressure groups', the 'squeaky wheel', who want SOME
   special path/exemption. This is Politics-As-Usual.
   The PROB is when you get like a CENTURY of this heaped
   upon itself .......
   How DO you write software for such a MESS ???

And the rules will be things like (made up, but the actual rules are
just as arcane):
 Person X receives 4.75% of their total SSA payments over their lifetime
as pension, unless they are also a veteran, in which case they receive
6.25%, but if they served in the Airborne rangers from 1975 to 1982
they get an additional 1.27%, however if they also worked for the NSA
from 1987 to 1993 they receive 1.87% less.  However, for payments from
1957 to 1962, they receive a 3.2% bonus, but for payments made from
1967 to 1974 they take a 1.4% penalty.  Further, if the payments were
for self employment income from 1975 to 1986 they get a 3.2% bonus.
Etc.
 Think about the arcane tax rules for what numbers to put where on the
tax forms every year, the SSA rules are very much like the tax rules
(because both have been created, piecemeal, over the course of decades,
by different politicians getting patches to the statutes through
congress).
 The problem that will be encountered is that the existing code base has
been built up over the decades in concert with the politicans making
changes, so both evolved in concert, and each change was incremental at
the time.  But trying to rewrite it all from the ground up is going to
quickly hit the quagmire of exponential complexity just to understand
all the rules about what to do when for some payment Y (or for some tax
filing Z).  The result will be something that either screws up royally
at every result, or simply omits 95+% of all the arcane, interdependent,
things the congres folk have added to the statutes over the decades
(and someone loses their SS payment the statues say they should
receive).

   The "existing code base" is mostly 60s COBOL so far as
   I can tell.
   It's been tweaked and tweaked and tweaked until it's
   a DISASTER nobody REALLY knows how to deal with.
   Whatever replaces it not only has to accommodate all
   the (oft ridiculous/illogical) tweaks but easily deal
   with any NEW tweaks in a sensible organized fashion.
   NOT easy at all.
   Hey, this is GOVERNMENT stuff ... not NASA calx.
   SUBJECTIVE results are paramount.
   Just one of those big black IBM mainframe clusters
   could run entire govt agencies - indeed even tie them
   together in an organized fashion. BUT, gotta have
   sensible underlying software/systems built on
   comprehensible, expandable, code.
   IS this possible - or did we create a MONSTER
   in the 60s ?
   The never-ending political tweaks ... a rule base
   COULD be implemented. This WILL include from/to/
   situational dates of relevance and such. GOTTA
   be easy to add new/over-riding rules.
   IMHO - I'm still gonna rec a UNIX base OS, then
   Python, maybe even BASIC, as the code base. All
   easy, no BS, no mystery, kinda self-doc. This
   should be good for another 50 years.
   After that ... it's gonna be all 'AI' and humans
   won't "get it" at all. Magic .......
   Anyway, anyone who thinks this is all EASY is
   full of it.
   Oh, valid arg, do you try to re-implement the
   current code base - or instead emulate what
   it DOES ? After consideration I trend towards
   the latter solution. Re-writing all that old
   COBOL would likely NOT yield good results ...
   so instead observe what it DOES - and write
   new code to do the same thing by alt means.