Complexity fascinates me: the more I learn about how computer hardware interacts with software, including the operating system, the more amazed I grow that it all hangs together as well as it does.
And when it doesn’t, and things come crashing down around our ears, I find myself glad to be the educated layman looking in on things from the outside, rather than the guy who has to make them work right again after they’ve crashed.
Software and hardware are bad enough, but mix in a dash of human creativity
and you’ve got a real recipe for disaster. Even when you plan everything scrupulously, and all your modifications to the network and server seem to go flawlessly, the odds are that somewhere, one or more users are going to trip over those changes and fall down hard. If those people happen to be in positions of power, or have friends who hold such positions, you’re going to be hearing about those pratfalls for a long time to come.
It’s obvious that almost all the changes you make will affect your user community, but it’s considerably less obvious how helpful that community can be about providing feedback before you make the changes.
For example, one company I know set up corporate e-mail access to the Internet long after they’d already established user IDs for logging onto the network. At the time, one of the planners recommended creating login names so short that nobody would mind typing them in: each account would be represented by a three-letter acronym based on initials, so for example, mine would be “ght.” This was a great solution because the company was small enough that there were few name conflicts, and it was easy to type internal addresses when you needed to send someone e-mail.
But once their e-mail became Internet-capable, someone pointed out that longer, more memorable names would be more helpful for their clients. So they implemented that system, and the simple three-letter internal addresses suddenly became longer addresses, with the elegantly concise “ght” becoming “geoff.hart@test.com.”
Unfortunately, nobody ever thought to ask the e-mail users whether the change would have any effect. And sure enough, that one small change brought down a whole line of dominos. Users who’d been profitably using work-related e-mail discussion groups suddenly found themselves unable to receive mail from those groups. Why? The old
e-mail addresses continued to receive mail, which was promptly discarded because there was no longer anybody by that name in the company’s mail directory. Worse yet, the new longer names weren’t registered with the discussion groups, so the owners of those names couldn’t rejoin the discussion until they figured out what had happened and resubscribed under their new names. A fair bit of useful information probably got lost along the way.
To complicate things, nobody realized it would be important to unsubscribe from the old groups, so the mail server received twice its usual volume of mail for a while: once to the old address, and once to the new. Even once everyone understood what was going on, there wasn’t a lot of worry about the problem until someone high up the corporate food chain got caught the same way and complained.
The problem eventually worked itself out, but not before the network manager’s reputation was tarnished. And what’s sad about this is that the problem could have been avoided simply by developing a group of knowledgeable users with whom to discuss the proposed changes and hopefully spot such problems – before they toppled a line of dominos that ended on a manager’s desk. The lesson? Even when you know the software inside out, you rarely know how people are using it. And that can hurt them, and maybe even you.
Hart (geoff-h@mtl.feric.ca) is a translator, technical writer, editor and a senior member of the Society for Technical Communication. He lives in Pointe-Claire, Que., where he works for a forestry research institute.
