04 December 2007

'A' Case for 'a' Case

“Oh no, there’s a computer problem.”

Normally said at an office, this sentence causes panic in most people. I work in an environment with employees that are… more technically skilled on average than most places, like, say, Dunder-Mifflin. I may be Dwight sans beet farm. I work for an automation engineering company. You might say the staff is good with computers.

But when something happens, even the employees are obligated- nay, required- to enlist the services of the dreaded IT department. These exchanges are usually comical to the IT staff, who have people walk through the troubleshooting kiddie-step by kiddie-step. I am infuriated at the pace of troubleshooting mostly because of the near condescending tone of the IT help staff, and frustrated that I can’t do this myself.

But a group of tech-savvy people, well, they may be able to solve the problem if they communicate well and have the system in front of them. Maybe. If they know how things work.
So our remote worksite, one at a client’s campus and not our home site, has been moved from time to time with relatively little effort. We use a wireless modem to conduct our internet business, thus avoiding the threat of attacking the client’s oh-so-secure network superstructure while being able to perform our day-to-day requirements. But from time to time, our IT department feels the need to perform an upgrade. This has happened twice and has been more disruptive to work than the four moves we have encountered.

What prompted the most recent disruption? We switched wireless modems.

If a computer is not programmed appropriately it doesn’t work, so sayeth the “garbage in, garbage out” edict. Technically a problem doesn’t really occur with the computers themselves. Most of the time, it’s what you told it that causes the errors. We got into that situation with the new modem, but we had to call IT first.

We understood the status of the machines, and we could describe what the problem was: the DHCP router wasn’t assigning an IP address. IT, however, doesn’t operate that way. They start from the beginning and reaffirm step-by-step what may or may not be the problem. The downside to that is that if you understand what’s going on and can tell them, they are required to do the same spiel. I was on the phone for two hours before the IT person said to me:

“Huh. So the DHCP router isn’t assigning an IP address. I wonder why?”

Through trial and error, the engineers managed to solve the problem. We also managed to find the source of the error. Instead of having a security key of 123ac456789, we were typing in a security key that was 123AC456789. Robots and droids worldwide titter with glee at the humor. The net cost was 48 man-hours lost to solving the problem. Over a week’s worth of work, because the IT person didn’t say “lower case ‘a’,” but just “type in ‘A’.” It wasn’t the IT person’s fault for thinking we were entering characters in the appropriate case. It wasn’t our fault for not specifying the case of the letter.

It’s almost always the thing you take for granted in communication that is the critical failure path.

2 comments:

The Chronek said...

That's crap that it wasn't IT's fault. There's too much case-sensitive stuff in networking and computers in general for someone in IT to not specify upper or lower case when typing in a password. They should never have assumed a lower-case password would be entered if they didn't explicitly specify it.
I'm sure the problem could have been anything, but still, whoever didn't specify that security key was case-sensitive isn't exactly looking all shiny.

Dan said...

We know. We all know. We looked at each other, and had an understanding. Our head IT guy's last name is "D u m a s". Not surprisingly, we take that and run with it. I'm just trying to convey this without coming across like I always communicate perfectly.