Think of Our Users

Edit: The technology may be different, but the principles are the same.

Originally posted January 5, 2010 on AIXchange

When I previously wrote about using my BlackBerry, I mentioned how it helps me in my travels.

I use my phone as my GPS, having it give me turn-by-turn audio directions to the different places I go. I travel quite a bit, and find myself in unfamiliar cities. I usually program the different addresses that I need before leaving, then bring them up on my phone once I reach my destination.

It’s been great for me. Of course I’m taking a chance that the GPS receiver and phone will always work, and that I’ll have network coverage wherever it is I am. However, I haven’t had any of those issues. But the one problem I have experienced is the one I didn’t expect–a failure with the application vendor as the source.

Whenever I drive a long distance, I usually wait to activate GPS. Generally I don’t need directions for the entire trip, just the very end of it. Why use GPS for, say, all 120 miles when I really only need it for the final five?

So recently I’m on the road and getting close to my destination. When I activated the application, I was informed of a critical update. I had no idea what the critical fixes were, and I only received two options: download the new application or quit. I would have preferred to download the update later, but no such luck.

I decided to pull off of the highway and download the application. It was a relatively smooth process. I was worried that I might have to re-enter an authorization code, but the application came right up when I restarted it. However, all of the addresses that I’d entered were lost.

It wasn’t a disaster. I had plenty of time, and I managed to find the one address I needed at that moment and plug it back in. But had I been in a rush and lacking ready access to the address of my destination, I could have been in some trouble.

This experience got me thinking about the testing that went into this code deployment. Did the application vendor really not consider the urgent needs of GPS users? How can you force someone who’s in transit to do an on-the-spot upgrade? At a minimum, users should have the option to perform such upgrades at their convenience. I know I like to upgrade when I have the time to work on any issues that might arise, not when I’m racing down a highway.

And thinking about that got me thinking about planned downtime and our own users. Do we administrators give them adequate notice and advanced warning about the updates we apply and the system changes we make? Do we test and verify in the lab, or do we push these changes without considering the consequences?

A friend keeps analog backups before he goes anywhere. He’ll print out the directions and the addresses he needs–just in case his technology lets him down. Do we admins take similar precautions? Before making any changes, do we make certain we have adequate hard copy documentation and sufficient backups, just in case our upgrades go bad?

The experience with my GPS was only a minor annoyance, but I wonder how many others have landed in a world of hurt by performing forced upgrades on the fly and losing all their information at the same time.

Let’s think of our users–our customers–whenever we make decisions that impact them.