I confess to a deep fascination with the seemingly mundane topic of logging. Software crashes, shopping cart abandonment, and security breaches are among the many situations in which you'll find yourself poring over logs trying to figure out what went wrong.Years ago -- it must have been more than a decade, because Win95 was then a beta product code-named Chicago -- I made a trip to Microsoft to be briefed on OS strategy. Win32 was young then, and its transplantation from NT onto the Win9x codebase was a big deal. Most of Win32 was slated to make the trip, but a few things got left behind, and the omission that most disturbed me was event logging.
...
Logs can flood us with information, or they can tell us compelling stories. We can influence the outcome by artful and iterative refinement of the data we collect. [Full story at InfoWorld.com]
The event log subsystem was left on the cutting room floor, an executive told me, because hard choices had to be made in order to bring Win95 in under its 4MB memory budget. This was not so absurd as it now sounds. Win95's competition was Windows 3.1, which could run in 4MB. (As it turned out, of course, nobody ran Win95 in less than 8MB.) But while granting the case for prudent conservation of scarce resources, I argued that it was vital to get developers of mainstream Windows apps into the habit of logging not just outright failures and errors, but also routine status information that could be used to analyze patterns of software use and guide incremental improvement of software.
Developers of server applications were then already making liberal use of the event log. If the hordes of developers coming to Win95 from Windows 3.1 weren't immediately enabled (and expected) to do the same, I argued, an opportunity to improve software quality would be lost for a generation.
So here we are in 2004, I'm running Windows XP on my desktop, and there's essentially no interesting data in the Event Viewer's Application log. What are some examples of things I'd like to see there? Off the top of my head:
Warnings. If the same warning appears repeatedly (or perhaps a set of related warnings spanning several apps), it's a sign that there's a problem with the software, or with the user's understanding of the software, or both. If we don't log these warnings, though, we can't detect patterns and respond to them.
Settings changes. As a user, how many times have you tried to remember what settings were in place when something that's broken used to work? As a developer, how many times have you tried to get users to remember what they changed? Aren't such changes important events in the life of an application, worthy of logging?
Launch and exit events. These are the most basic and obvious things to record, but we don't find them in the log. If we going to move toward "software as a service," shouldn't we keep track of what's used and how often?
Ironically there are much more detailed logs of our routine software activities on other people's machines (i.e., on Web servers) than on our own. There's no reason why this has to be so, and plenty of reasons why it shouldn't be. It's an accident of history, really. A questionable decision made during an era of resource scarcity now serves us badly in this era of abundance.
Former URL: http://weblog.infoworld.com/udell/2004/05/27.html#a1010