Design Flaws

It would have been a good day to call in sick. (1) It was raining, and (2) I was scheduled for three meetings. If that's not an excellent reason to stay home, nestled in bed with a good book and a couple of fair-to-middling cats, I'd like to know what is.

The early meeting was held in our department's library-cum-conference room, which (despite what I just called it) is not a very exciting room to be in. The meeting wasn't particularly interesting either; plus I was there just to observe, so it was more than usually dull, to the point where after a while I seriously considered leafing through the proceedings from the US Army Corps of Engineers 1991 Dredging Conference, just to help pass the time.

I wonder how far dredging technology has advanced since then?

Then this afternoon, our department was on the receiving end of a presentation by our Automation guys to show us a new software application they'd designed to streamline a process we share with them.

Automation exists to automate processes, hence the name. I don't think they do any evaluation, though. Therefore, the main function of their existence seems to be that of wrapping the latest, cutting-edge technology they can get their budget on, around the most preposterously antiquated processes the agency has to offer.

This particular application is a web-based one, designed to streamline a process that exists, unchanged, from before the Internet was so much as a glint in ARPA's eye. It's a process our department has the good fortune to share with Automation, so they wrote it to make things easier on them, without it apparently occurring to them that others might be involved. The end result saves them a small amount of running around, while adding several steps to what we do.

The web-based application has database functionality, and accommodates multiple users making updates at once. However, each user transaction requires a unique key, which has to be manually set by the user. So what if two (or more) users are online at the same time, and set the same unique key?

"Oh, just refresh your screen right before you save your transaction," the presenter said blithely. "Or after you save it, just go back in to make sure you didn't create a duplicate number, and if you did, just edit it and make a new one."

Well, that seems so easy, one feels rather petty for complaining; but wouldn't it be simpler, one couldn't help but ask, to have an automatically-generated unique index key that wouldn't allow for duplications?

There was a pause. "That's probably a good idea for an added feature in the next version!"

Another advantage of the new system is that it's supposed to eliminate a lot of unnecessary emails. You see, currently an Automation staff member has to compose an email and send it out every time someone sends them a transaction, notifying the recipient that the transaction has been received and processed, and whether it has any errors. The new system will automate all this.

Of course, it does so by sending an auto-generated notification to whoever has alerts turned on, not just the one person who may have sent a particular transaction. So you'll get alerts every single time any transaction, sent by anyone, has been received.

"Well, just turn off alerts if you don't like to get a whole bunch of emails," the presenter said, trying hard to remain patient.

But what (we are a difficult group) if you have transactions being worked on, but don't want to get all the notifications about everybody else's as well? Moreover, what if you'd kind of prefer that all the details about your transactions - such as your error record - not get sent to all your coworkers, God, and everybody?

The Automation presenter was getting rather testy at this point. "Look," she said. "What do you always do when you get a lot of extra emails? Just delete them! You know how to use the Delete key!"

The meeting went on, and on, and eventually it was explained to Automation that multiple people in our department will always be sending lots of transactions at once. It is, in fact, kind of, not to put too fine a point on it, our whole entire job, which they might have known if anyone in Automation had bothered checking with us before writing up the application. So they grudgingly agreed this particular aspect of the software might need a little work in the next version.

So help me God, if anybody calls any meetings tomorrow, I'm going home sick. Oh! my leg!