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.

Career Opportunities

So I've been presented with an opportunity at work.

Well, perhaps "opportunity" is the wrong word, as it was presented as a sort of opportunity/ultimatum hybrid.

In essence, I have been given (in addition to all my regular work) the task of managing the transition of the entire ticketing system for [the theme park at which I work] from one database system to another. If I manage to do this by some nebulous target date (likely in September, which is a joke for a different post), I will be anointed with a new title, purportedly containing that mystical word of power, "manager." If I fail ... well, let's not dwell on that.

In order to do this however, I need to learn to write effective "Use Cases." In order to do that, I have been given a book, helpfully titled, Writing Effective Use Cases.

Now, if you're not a total corporate stooge, you are probably asking yourself, "What is a use case?" (That is, if you haven't already stopped reading this already.) Well, let's take a look at the first paragraph of the introduction, helpfully titled, "What is a Use Case?" shall we?

A use case captures a contract between the stakeholders of a system about its behavior. The use case describes the system's behavior under various conditions as the system responds to a request from one of the stakeholders, called the primary actor. The primary actor initiates an interaction with the system to accomplish some goal. The system responds, protecting the interests of all the stakeholders. Different sequences of behavior, or scenarios, can unfold, depending on the particular requests made and the conditions surrounding the requests. The use case gathers those different scenarios together.

If that doesn't make you want to yank out your eyeballs and feed them to the cat, congratulations! You may have a future in project management! I, in contrast, am now haivag ar d time tpying withoyt eyvslls.

Seriously, though: does this paragraph in any way clarify the concept for you? At this stage of the game, a "use case" could be anything. Is it a diorama? An essay? A pictogram? A standing stone engraved with the catchphrases of the ancient druids?

If there's one thing I hate, it's businesspeak.

Actually, if I was restricted to one thing, it would probably be "cruelty," but it's my blog, so I'll hyperbolize (hyperbolate? hyperbolitize?) if I want to.

Those Were the Days

As you may or may not know (and almost certainly don't care), my formative career years were spent in the service of that stalwart cornerstone of American commerce, Kinko's. That's right, I was there. I was there when they came up with the slogan, "Kinko's: A New way to Office." And it made as little sense then as it does now.

Ah, those were good times: getting accosted by insane drifters who want to photocopy their poorly-worded manifestos, being exposed to tuberculosis, spending a relaxing lunch hour in the half-flooded, flea-infested basement with the rats, and earning a hefty $9.25 an hour in New York City.

Well, times have changed, and Kinko's is now part of Federal Express, but it's gratifying to know that, deep down, they really haven't changed that much.