No one!
Seriously, this is the problem we face all the time when users run into a problem with our software. They don't call, they figure out an inefficient work around, they get frustrated, or stop using the software. It's counter intuitive but I've seen it over and over again. The reasons and excuses are endless but it all boils down to the fact that few problems are ever going to make it back to you.
Have you read Joel Spolsky's The Joel Test: 12 Steps to Better Code? You should. I like it enough to add a thirteenth step, log all error messages. Logging errors to a file that no one reads doesn't count. You need to track the errors so that you can be proactive in finding solutions.
We took Manoel Marques's Plugging in a logging framework for Eclipse plug-ins and extended it so all errors are logged in a database, emailed to our user support group and appropriate software developers. We've even gone as far as having wiki pages that shows the latest trends in real time.
This doesn't mean we're being constantly interrupted during our work day. But it does give us the flexibility to monitor users and jump in to solve either a usability, training, or software bug issue.
Eclipse is robust. I've been amazed at how well it handles nasty NullPointerExceptions without crashing. Don't get me wrong, it is a good thing but it can hide problems from the user. In alot of cases our users don't know they are in trouble until we burst into their office like Murray, Aykroyd, and Ramis looking to bust up a few ghosts.
We found it a great help to extend Marques's code to allow us to customize the logging properties. We allow log properties in the following order.
- Load from the users home account
- We can drop a custom logging properties file in the users account, restart our application and we can monitor whats happening in greater detail.
- Load from command line
- Customize logging from the run configuration dialog. Developers use this to avoid inundating the group with errors.
- Load from bundle
- This is what is shipped to our clients. Thanks to Eclipse plugin fragments each client gets to setup their own settings.
- Load from default
- In case the log properties file is broken, we have a default setup. Paranoid you say. Yep!
We have a set of standard logging tags. When you playback the log file, think airplane black boxes, it makes it easier to figure out what the user was doing leading up to their problem.
public interface ILoggingTag {
public static final String DELIMITER = ":";
public static final String SPACE = " ";
public static final String CREATE = "CREATE";
public static final String OPEN = "OPEN";
public static final String CLOSE = "CLOSE";
public static final String START = "START";
public static final String STOP = "STOP";
public static final String FINISH = "FINISH";
public static final String DELETE = "DELETE";
public static final String CANCEL = "CANCEL";
//......
public static final String PLUGIN_START = PLUGIN + DELIMITER + START + SPACE;
public static final String PLUGIN_STOP = PLUGIN + DELIMITER + STOP + SPACE;
public static final String RESOURCE_OPEN = RESOURCE + DELIMITER + OPEN + SPACE;
public static final String RESOURCE_CLOSE = RESOURCE + DELIMITER + CLOSE + SPACE;
}
Our code looks like this.
@Override
public void init(IEditorSite site, IEditorInput input) {
//...
logger.info(ILoggingTag.EDITOR_CREATE + input.getName());
}
@Override
public void dispose() {
log.debug(ILoggingTag.RESOURCE_CLOSE + getEditorInput().getName());
//...
}
We log messages to the users log file, to a PostgreSQL database, and send emails. Having errors stored in a database allows use to generate wiki reports showing the latest trends in usage, bugs, etc.
The payback; obviously fewer bugs but what was really important was a more relaxed user community willing to help use improve the software. In many cases we're not tracking down software bugs but working to improve software usability. Users want to use our software, I have more time to spend writing new code, and tracking down bugs takes less time.
2 comments:
Excellent.
Developers usually understand the importance of logs after they have to support users who may perhaps not be accessible over a phone call.
When I used to write Swing based Apps, I used to provide a menu option called "Generate Logs" which would write out the Java System Properties, the state of the app, and the contents of the various file system based logs, and then create a convenient zip file which the users could send to me via email.
I just remembered that I'd iterate over the System Properties myself because the default writer for Properties had a line length limit of 39 characters, I think.
Anyway, an excellent post. The wiki based trned monitoring is a good idea that I'd not thought of before.
Good to see you writing again!
We try to log a number of things for DTP, so I get the need to log errors and warnings and such to provide better support to users. I wonder though how easy it is to add tracing to the workbench not running in debug mode. It might be nice to have a user who finds an error turn on tracing, reproduce and provide steps, then turn off tracing, so you have some kind of facility for generating this sort of error metadata.
Post a Comment