Re: worst RPG ever seen?

I recently had the distinct displeasure of working on a program that
was written by a guy I worked with about 16 years ago.  luckily, I
never had to directly work with the guy on a project back then, as his
reputation preceded him and I refused.

He moved on and sub-contracted at the company I'm working for now.

This program was a bloody mess.

22K lines of code.  It was an order detail mass maintenance - allowing
change of multiple lines on multiple orders, based on selection
criteria.  It updated the order relationships between about 20
different files.

Their were 8 screens, all of them nearly exactly identical except for
one or two fields out of a hundred or so on each screen - but the
fields were all named differently.  The subroutines to process these
screens were likewise nearly identical, except for about 1% of the
lines of code, and of course the different field names.

each screen had about 20 subroutines that were used to process them,
and they were named sequentially:  SUB1#A, SUB1#B, SUB1#C....  SUB2#A,
SUB2#B, SUB2#C.... ect.

he didn't use indicators, but what he did was worse - he used
attribute byte fields that he also named sequentially - fa1#01,
fa2#01, fa3#03... etc.

That was not the worst of it.    for each of the 8 screens, he had 6
different data structures with hard coded beginning and ending
positions, so that he could pass the data back and forth between the
data structures easily - a nice technique if done right, this wasn't.

typically, a single "setoff" and 3 or 4 "verify" subroutine would be
called at least 10 times for each <enter> pressed.   Sometimes the
verify subroutines would work with the screen fields, sometimes they'd
work with the datastructure fields.  sometimes both at once, sometimes
several different DSs at once.

to make matters worse, it always dropped clear out of a subroutine and
reentered another subroutine based on the value of a variable that he
would increment like so:

sub#   caseq 1      sub1#A
sub#   caseq 2      sub1#B
sub#   caseq 3      sub1#C
sub#   caseq 4      sub1#D
...
...
begsr
...
add   6   sub#
endsr

For days, I would step through this thing in debug mode, never really
knowing where I was, and for what purpose.  In 23 years, I've never
been as frustrated from working on a program than I was this time.   I
was very close to giving up - actually stating to the customer that,
no, I refuse to work with this thing any longer.

after about 3 weeks of screwing around with this abomination, I
suddenly had an epiphany about the rhyme and reason for a couple of
the more damnable parts of his code, and was able to make the
necessary changes and get rid of it.

Several people have told me that this guy admitted to purposefully
making his programs as difficult to read as possible, even throwing in
every trick he could think of to obfuscate the actual intentions of
the code.

The reason?  Job security.   yes.  Those people do exist.

I wished I had actually worked with this dud back in the day, because
I would have surely strangled him.  If a programmer was on the jury,
I'd be aquitted - if not, no jury in the land would have given me
worse than manslaughter, and by now I would have been out of jail, and
would never have seen this program.

Now, i'm the order detail mass maintenance expert here, so if they
need more changes, I'll be the guy.   I can't wait.

Rick