In the last few years, I’ve performed quality assurance testing on code written by a number of different people. Most of these developers never moved code into production that they hadn’t tested themselves. (However, some of the Java- and C-brains I’ve worked with have thrown together first drafts at the last minute and left the debugging for QA.)
In the last few months, though, I’ve been wearing my developer hat again, and it feels great. In fact, I recently used a time-honored, somewhat-sneaky-but-perfectly-legal trick to foil an attack on my application by a dubious user. I call it the event log. As a developer, it’s my very best friend when I have a meeting with my client. Here’s the scoop.
He says, it says
I’ve recently been developing an application on a consulting basis, and one of the end users is constantly finding fault with my code. Unfortunately, the bug reports amount to little more than “I did exactly what I was supposed to, but it didn’t do anything.” That kind of nonspecific testimony reeks, but the client—the person who signs the checks—got spooked by it. I got called on the carpet.
When I showed up at the client’s office, the first thing I did was volunteer to try the application myself. I used the same machine and the same application the user claimed “didn’t do anything.” Naturally, everything worked just fine while I was at the keyboard. The user shrugged, and the client furled his brow.
I knew the user was lying, but the problem was how to prove it. Fortunately, I learned long ago that virtually every programming language includes the tools you can use to create an event log. At any point in your program, you can write a line to a text file or add a record to an event log table.
The event log basically contains a record of everything that happens while a particular program is running. Generating an event log requires a little more effort than just writing and compiling some code. However, taking time to create an event log provides a developer with two big advantages: easier debugging and easier troubleshooting.
1) Easier debugging
Syntax errors get trapped by most debuggers, but logic errors are harder to spot in advance. When you write errors and successes to your event log, you can verify that a particular code snippet has run successfully or capture any error messages that occurred. Then, during testing, the event log lets you know what happened at each stage of your program.
In my event logs, I typically write entries stamped with the date and time and phrases like:
- “The user just selected option 3 from the main menu.”
- “The user apparently didn’t put the disk in the drive.”
- “The Customer database was opened for editing.”
- “The Call Sheet was printed for X customers.”
2) Easier troubleshooting
With my most recent client, there was a discrepancy between what the user claimed to have done and the items recorded in the event log. “I pressed this, I clicked that, and nothing happened,” the user testified.
“And you tried to do that about what time?” I asked.
“About such-and-such a time,” the user answered.
I told the user I’d take a look at the code. Then, in private, I introduced the client to my best friend, the event log. I opened the file and respectfully pointed out the items in the event log that were logged around the time the user claimed the software had crashed.
The entries showed the exact time when the user logged in, which menu items were selected, and the exact time the user closed the program. I won’t bore you with the details, but here’s the gist: The user had logged in, clicked around, and exited the program—without entering any data or completing any tasks!
Here’s the nicest thing. I was able to point to the event log and show the client where the program had just recorded every action I had taken only a few minutes before. Those time stamps gave credibility to the event log.
Don’t submit your code without it
If you’re talking about batch files or application-specific macros, maybe creating an event log is overkill. But if you’re writing code for customers of any kind (including in-house end users), create an event log.
The time you spend coding the event log will pay for itself many times over during debugging and field-testing. Here are two last tips: First, define a logical value at the top of your app that says, “capture” or “don’t capture” event log data. That way, you can control whether some or all of your error-trapping routines are active. Second, if you leave the event log active in the application you deliver, make an allowance in your code to delete (or archive) the log file periodically.
If not for the event log, I probably would have lost that consulting client. Can you relate? Post a comment below or follow this link to write to Jeff. Subscribe to the View from Ground Zero TechMail, and you’ll get a bonus of Jeff’s picks for the best Web stuff—exclusively for TechMail subscribers.