I'm Just Writin' to Keep from Screamin'

Code Monkey Rather Eat a Coffee Cake,
Take Bath, Take Nap.
"This Job Fulfilling in Creative Way."
Such a Load of Crap.

If you know anything about programming, you know that programs have bugs in them. Anything that does more than say "Hello World!" is going to have bugs creep into it. It's just the nature of the beast.

When you're dealing with databases, the bugs are practically built in before you start writing the code. That is due to two factors:

1. Data is entered into databases by users.
2. Users are idiots.

This may seem harsh, but the facts are plain for anyone to see. When presented with a field helpfully labeled "First Name" and another labeled "Last Name" a user will cheerfully put the first name in the last name slot, and vice versa. A particularly insidious user will put both first and last name in the first name box and consider it a job well done.

Here are some of the amazing database entries I've had to deal with on my most recent project:

• People who bought passes for their whole family: John and Jane Doe and their baby. The clever and insightful person responsible for entering their data dutifully created an entry for BABY DOE.
• Another family did the same. Their baby's first and last names were entered correctly, except that the last name was entered as "DOE (CHILD)." Guess whose last name is no longer the same as their parents?
• "John X. Doe" First Name: JOHN. Last Name: X. DOE. Someday I hope to meet the entire X. DOE clan and tell them how cool their last name is.
• Meet the SMITH*** family, mysteriously endowed with three asterisks after their last name! The meaning of this hieroglyph is lost in the mists of time.
• Or how about the V-REYES family? What does that even mean?

Lest we believe this solely a user problem however, consider this:

I wrote a simple application that retrieves data from a card holder database based on the serial number of the card. Other programmers were supposed to create a simple form for cardholders to update their information on-line. Simple, no?

Since some of the fields contained no information, I wanted to be clear about my responses, so I informed the programmers (in writing and over the phone) who would be calling this application that a field containing no information would be reported as "NO VALUE" rather than blank, to let them know that the query worked, but retrieved nothing (as opposed to not working at all).

So what do I see populating every formerly-empty field in the database after a user updates their info?

"NO VALUE"

That's right. They paid no damn attention and populated fields with "NO VALUE" rather than treating it as a field with ... no value.

Then there another task I was given:

Boss: Import these fields from this text file into this table.

Me: Done.

Boss: Oh, wait. Actually, we need this field also populated, which you'll have to get by checking this other table. You really should have done that in the first place.

Me: But you said ... never mind. OK, done.

Boss: Well, we didn't want all of the records imported. Only certain ones, based on this other table.

Me: Well, if you'd told me that in the first place ... Okay, d--

Boss: Wait, are you importing just the records from this text file? Because we really need you to import the records from the turnstiles and then just match them up to the ones in this text file.

Me: Okay, but--

Boss: Oh, and we have to have it done immediately. I mean you've been working on it for days!

Me: Yeah, but you keep--

Boss: And what about the update for the web service? There's all these fields with 'NO VALUE' in them. What does that even mean?

Me: IT MEANS YOU PEOPLE ARE ALL #!@&*ing MORONS AND I'M GOING TO HAVE AN ANEURYSM!!!*

*Code monkey not say it out loud. Code monkey not crazy, just proud.