OmegaMom

Dear Very-Distant-Coworker:

When I sent you the email asking you a whole list of questions about how many copies of a particular document you received, I didn’t want a reply of “Yeah, I received a bunch.”  I asked you who you received them from, how many copies you got, and when you received them because (whaddasurprise!) I wanted answers so that I could track down the problem at our end.

Sincerely, OmegaMom-the-support-person

Dear Coworker-of-OmegaDad’s:

When he sent you the email stating that he would be in your town to do training, that he needed all people there for training, and asking what would be a good week for this, he did not need a two-page reply outlining all your difficulties, listing everyone’s schedule for two months, and a request for special trips to train Joe, Moe, and Schmoe.  Please don’t get angry when he replies quoting his original email and repeating that he needs all people there for the training.

Sincerely, OmegaMom-the-spouse-who-likes-to-see-her-husband

Dear L0we’s:

Please train your cashiers to use the L0we’s part number, rather than the manufacturer’s part number, when entering data.  That way, we won’t be told that parts that we know are in stock are out of stock and now on special order.  Oh, also, you won’t charge us for special ordering.  And we won’t have to deal with the front desk or the head cashier to get a credit.  Which we can’t use anywhere else.  Which might have been nice to have in our bank account, instead.  Hey, maybe you can start offering, say, checks to people for such overcharges?

Also, this time around, please be sure to deliver when you say you’re going to deliver.

Also, this time around, please be sure to deliver everything we ordered, which was in stock when we ordered it, rather than surprising us at delivery time by not having everything we ordered.

Does this make sense?  Good.

Thank you, OmegaMom-and-OmegaDad-about-to-embark-on-another-chicken-coop-for-smaller-birds

Dear Fruit Flies:

This is a declaration of war.  Die, die, die!

Sincerely, OmegaMom-the-lousy-housekeeper

Dear Kozmik All:

What have I done that I should deserve this ongoing itchy scalp?  The doctor’s antibiotics are not helping.

Sincerely, OmegaMom-the-itchy

Well, actually, yes we do.

A few weeks ago, I wrote about my little mystery hunt trying to figure out why the vehicle reservation system in my department of Small Mountain University was on the fritz, how I discovered that the unique identifier for each reservation was limited to four digits by Nice Young Intern, and how sometime in the past few months, we had hit 9,999 and the reservation numbers started all over again at 1, causing all sorts of funky errors.

My readers in the biz were appalled.  "Where was the code review?!" they proclaimed.

Yah, well.  (OmegaMom looks aside, shuffles her feet, coughs a bit…)

I love working at SMU.  I really do.  I started in the ITS department, got chopped in the Great Layoffs, took a (much less remunerative) position as an administrative assistant while waiting for IT jobs to re-appear, and then got my position in Current Department when the job market started warming up again.  The atmosphere on campus is collegial.  There are lots of cool folk doing lots of cool things on the academic side; there are lots of cool folk doing lots of cool things on the ITS side; there are lots of cool folk doing less cool but immensely important things on the business side, and almost everyone I’ve worked with at SMU has been intelligent, interesting, fun, and good to work with.  (I can think of two exceptions over the past nine years, that’s all.)

Anyway, in the ITS department, since we have lots of folks there, many ITS things were (and are) done by the book.  Good coders, good reviewers, good interactions between everyone.  But there are only so many ITS folk to go around, and those that are tasked with helping on more complex projects outside ITS are booked solid for a year in advance.

Out in the departments, there are IT folk who are hired as departmental support.  Itty bitty departments have to make do with no-one, or sharing someone with a few other itty-bitty departments.  Bigger departments get one or two.  Really big departments get their own geek squad.

Each of those support folk have to handle a wide variety of different issues.  There’s day-to-day support:  Figuring out why JoAnne’s email suddenly disappeared.  Helping Dr. Professor Jones stitch together a master document and sub-documents in Word (and trying to explain that master- and sub-documents in Word have a really bad reputation for getting corrupted and frying your entire 417 page manuscript).  Updating web pages.  Maintaining small databases.  Developing interfaces to bigger university systems, or maintaining old interfaces that have been just chuggin’ along for many years but need a tweak or two now and then.  Arranging repair for old equipment.  Buying new equipment.  Figuring out equipment budgets for the upcoming year.  Buying color toner when something needs to be printed in color RIGHT NOW!  Crunching numbers in spreadsheets.  Putting together pamphlets or brochures or quarterly newsletters.  Getting new people set up on systems and into the university system.  Running local servers.  Maybe running computer labs for students and staff.  Providing down-and-dirty training.

Rarely a dull moment.  Always fun to help people.  Good to get to know folks in all aspects of the higher education biz.

It’s sort of like juggling.  There’s always something that is urgent.  Typically, the urgent stuff is related to ensuring that everyone in the department is able to do their work.  Then there are the bigger departmental projects…which get done in and around the "making sure everyone can do their work" everyday stuff.  You’re catching the errors on this database while crunching the numbers for that report to the board while uploading PDFs to the website while figuring out why the network has gone down for the people in room 219 while…

What ends up happening is that whoever gets handed the bigger project just bulls in and does it. 

Like the project Nice Young Intern worked on.

It gets done, it gets tossed up, people who are chomping at the bit to get to use the project start working on it (ostensibly as testing) and then suddenly it segues into being used.  And rare is the chance to get someone to give your code a review.

I’m pretty sure Johnny and SpaceMom are shivering in their boots at that mild paragraph.  Where’s the project outline?!  Where are the specs?!  Where’s the test plan?!  Where’s the code review?!  Where’s the iterative process?!

I know, I know.  At times it bothers me, too.  But y’know what?  It’s really fun work.  You get to be a jack (or jill) of all trades.  You get to help people.  And all of these "bigger" projects are really, in the course of things, small potatoes; they’re "big" in relationship to the day-to-day stuff at the departmental level.  It’s not like the small army of coders and testers and code librarians and project managers handling a Truly Important Project like the online education program or the accounting program or the human resources program.  Those projects are vital, necessary to the lifeblood of the university as a whole.  They’re handled by ITS, they’re treated like good software projects should be, they take time and money and people and organization.  Those projects get code reviews out the wazoo.  Smaller projects that ITS takes on, handled by one team or another, also get the software project treatment.  But projects handed out to departmental support folk?  Those get dropped on the desk as a "Y’know, it would be nice if we could do x, y, or z.  D’you think you can pull something together in two weeks?" 

NYI’s project started that way, and my predecessor knew that it would probably not get done in any decent amount of time unless she borrowed a student from the CS or CIS programs.  It made a good summer project for NYI, and he did think it through, provide specs, program it, and get it up and running.  Since he specified only four digits for the reservation number, I’m thinking that people talked it over and figured that the program would be replaced long before they needed to worry about it.  Sort of like Y2K.

But code review?  What a luxury that would be!

(Technical stuff follows.  Feel free to ignore.)

Oooooo!

So there we are at work…our transportation center has an online reservation system that was written by a Nice Young Intern.  It was written back in 2002 and has worked okie doke since.  (Aside from the fact–which I discovered recently–that it has been running on the development server all this time, rather than the production server.  To those of my readers to whom that is an arcane distinction, let me just say:  production servers have paging systems.  If the production server goes down in the wee hours of the night, some poor ITS minion is paged and required to dash in to the office to Figure Out The Problem Right Now!  This does not happen with development servers.  If a development server goes down, the priority to get it going again is low on the totem pole.  Also, DBAs feel quite happy to Do Things to development servers, without worrying that they’re going to break something.)

Recently, we’ve been getting complaints from our TC that the users of the online reservation system have been getting errors.

I investigate.  Luckily (or not so much ‘luckily’ as ‘almost inevitably’, as it turns out), I immediately get an error page.

(Let’s set aside the fact that there’s no error checking, so we don’t have a “nice” error page telling our users that oops, there’s a problem, and please try again later??)

The error page says “unique constraint violated’.  What the heck?  Why would that happen?

Interestingly enough, the DBAs had just updated the development server shortly before the TC folks really pushed us about this error.  So I went down that path for a while.  But a DBA, when emailed, provided a clue–he said that we’re trying to insert new rows with a duplicate primary key.  (A ‘primary key’ is a number that uniquely identifies a row in the table.  For instance, if you’re doing a credit card transaction, the primary key might be, say, your transaction number.  No-one else is going to have that transaction number…or no-one else will have that transaction number on that date, so the primary key would be trans number plus date.)

I noodle around.

I investigate.

I discover, much to my absolute and utter horror…

The Nice Young Intern had set up the reservation numbers as the primary key.  This is okay.

The NYI had an automatic number generating doodad set up in the Oracle database to generate those reservation numbers.  This is okay.

The NYI had not used the default maximum limit for the reservation number–which would be some gawd-awful number like 999,999,999,999.

No.

The NYI created the reservation number system to have a maximum number of 9999.  This is not okay.

So…once the TC had gotten reservation number 9999, what happens?

The automatic numbering system starts all over again, at number 1.

Back when the system was being developed and tested, there were loads of jumps in the numbering system.  NYI would try a reservation, it wouldn’t work, he’d back out, that reservation number would be discarded…But as the system went online and real people started using it, the gaps in the numbering system would become fewer and fewer in number.

The first few hundred numbers worked okay.  Users would get an error once every great while, when the system tried to save a reservation that had a reservation number already used in the system.  But now…now…the gaps in the numbering system are few and far between.  Thus, as I said above, it was almost inevitable that the test reservation I made would not go through.

Why the fuck would someone create a system keyed on an automatic number that rolls over when it hits 9999?!  This is like our own little tiny version of the Y2K problem.

And I’m hopping mad about it.

Luckily, it’s an easy fix.

Grumble, grumble, grumble, bitch, moan, complain.