Crunch Time

A few years ago I switched jobs.  The team I was put on was working
on converting COBOL to C#.  It is a pretty big project and only now
(next week) are we going to start deploying it.  The company I work
for is retail, we get things ... we sell things ... we ship things.
The part that we're converting from COBOL to C# is the shipping.
It's legacy code that's been there since the 60's (or at least 70's)
and has grown, evolved, been bandaged, been refactored, has dead
branches (code that is no longer accessible or used), in short,
complex.

We started out as a team of 4, and one COBOL guy not technically on
our team who we leaned on heavily to answer questions.  But over time
we've lost 2 devs, one quit for another job and another moved to a
different team working on other things.  So it was just me and one
other guy (the team lead, C) for a while but eventually the COBOL guy
joined our team and has picked up some C# knowledge so that has been
helpful.

We have hired replacement devs (two) but they are working on other
things although one I'm trying to get involved in this project and
when her work ran out I suggested to C to ask her to go through the
code we've written and diagram it.  This should be helpful for her to
understand all the moving pieces but also we are going to need those
diagrams for maintenance and a huge refactor that's coming up.  I'm
hoping that if she understands it a little she can help us with
issues that might pop up after deployment.

I think we spent thrice as much time on testing as we did on the
actual coding.  There was one area that didn't get a proper test
however, it has to do with printing.  It's a very niche test case, it
only applies for a tiny fraction of products.

There was a handful of issues with it that weren't caught and the
project manager (not the same PM we started with) was kind of
freaking out that the deployment might get delayed because it was
taking a long time to fix it.  The issue itself wasn't too
complicated, what was hard was testing a change.

One of the reasons it went uncaught was that we had another bug here
that was hiding these issues:  If something went wrong printing then
... silently keep going?  What *should* have happened was: Break,
error out, yell, complain, be the squeaky wheel.  Shout from the
mountaintops that the printer isn't working and you're going going to
proceed processing the order until someone does something about it.
So that was the first fix.

Since we all work from home we can't just walk over to the printer to
see if it printed correctly.  However there are some people who chose
to work in the office.  They probably live a lot closer to the office
than I do.

So here's the text/fix cycle: I'd make a change, deploy it to the dev
environment, run a test, ask M (the guy in the office) to check the
printer.  Unfortunately it usually takes this person hours to
respond.  I have no idea what he's doing there in the office but more
I just feel bad constantly distracting this guy.  I mean maybe he's
just standing around with a mug of coffee yammering at people like on
office space but it's also just as likely (it not more likely) that
he's knee deep in his own projects and just doesn't have time to run
around looking at printers.

The first hurtle was just finding the printer.  We sent a document to
the printer, no errors.  We can ping the printer, we can connect to
it.  But no one knew where it was.  Since this is not a production
printer it could be anywhere; a closet, a bathroom, some other
building...

Eventually it was located and the photo sent back to me was not good.
 This area of the code was translated from COBOL to C# by the dev
that quit but I can already tell it's completely wrong.  Control
commands that are supposed to tell the printer to position the next
block of text at a particular coordinate are not being executed,
instead it's just printing those control codes.

But, luckily, J (the COBOL guy) still had some files from when he was
writing the COBOL version of this.  He had some data files of print
jobs (successful, correct, print jobs) and using a hex editor I could
see where R (the person who had coded this part of the program and
subsequently quit) went wrong.  So I fixed that, sent a print job,
asked M to go checked the printer, had another meeting with the PM to
try to calm her anxiety.

About 3 hours later I finally got a photo back from M.  Formatting is
correct!  Data is missing!  Oh boy.  So now the day is growing late,
C (other guy on my team) has taken off for the day and will be out of
town tomorrow.  PM says if we don't have it fixed by Monday we'll
have to send out a notice that the deployment will be delayed.  I
have about 30 minutes left in the day, I make a few changes I build
and deploy, I run a test, I ask M to check the printer ... silence.

So I go on with my life.  I log off, I go lift weights which is my
Thursday thing.  At the end of the day I go to bed anxious knowing
that I (and I alone since C is out of town tomorrow) have exactly one
day to get this fixed and it depends on waiting for M (who may or may
not even be in the office on Fridays, a lot of people aren't) to send
me photos of printouts.

When I get up I do my morning ritual, spend some time BBSing.  I tend
to just grab my coffee and cereal and go straight to my Commodore 128
because I know if I turn on my PC's monitors I'll get distracted so
all that can wait until BBSing is done.

After BBSing, turn on my monitors, and see a message from M sent
about an hour after I logged out.  It's a photo of the printout.  And
...


It's GOOD!

Yes!  I can relax a little today.  Take time to write this phlog,
clean up my code a bit, and breathe.
.