Debugging Users and Invisible Characters
As a developer working for a startup with live software in the field, I often have to problem solve some interesting and out of the box bugs. One recent bug was related to changes to the Daylight Standard Time and Sun’s Java Timezone Updater, which is far from the control of my code. The Timezone Updater is a simple Java application that can be run as follows.
"c:\Program Files\Java\jre1.5.0_10\bin\java" -jar tzupdater.jar -f -bc
After documenting, testing, and validating the process of running the Timezone Updater from the command prompt we had our sales engineer upgrade the all of our clients’ JRE with the current timezone data. After some time we had reports that some clients had a problem running the above command, they where getting the following Java error.
Exception in thread "main" java.lang.NoClassDefFoundError: ûjar
It seemed that Java could not find a class named ujar (notice that funny hat over the u). Our sales engineer, with the aid of a software engineer, spent all day going back and forth with the client. As you might have guessed, updating the timezone data worked for our engineers but at the client site they consistently got the above error. After a long email thread full of instructions, screen shots, and frustration I was pull in.
I too was unable to reproduce the error until I considered the error. The only clue in the above error is the funny character u. After some time it occurred to me that the -jar had been corrupted into ujar. But what would distort the dash? Word. The instructions to run the Java Timezone Updater where written and sent in Outlook and cut and pasted from Outlook. Outlook uses Word as the default mail editor and Word has the awful tendency of distorting plain old ASCII text into special characters at will, try typing :) in Word.
This bug was not obvious to our client’s IT personnel, our front line sales engineer, and an experienced software engineer. Having code working on the developer’s machine is not a valid solution, software needs to work at the client’s site too!
One lesson that most developers don’t learn is to debug outside the debugger. As an engineer there are times you need to trouble shoot, problem solve, and debug not just your software from the comforts of your favorite IDE but the whole software stack, network, hardware, user’s environment, and even the user himself.
Every problem, issue, and bug experienced by the end user directly and indirectly with your software eventually needs to be implicitly and explicitly dealt with by your software development team. Bugs that are on the fringes of the code base are the most difficult to solve, that is why each member a software development team needs to take full ownership of the whole code base, and every known issue.
Technorati Tags: debug, troubleshoot, timezone, test, users, word, outlook