Participatory debugging

Applications increasingly rely on components and services that can turn up in unexpected contexts. I wasn't expecting to see a Mac OS error code on my Windows box, but in a mix-and-match world that happens. Reporting the provenance of error codes would be a helpful best practice.

Enabling users to visualize configuration change would be even more helpful. The default path remembered in that dialog box is part of the application's configuration. When the problem arose, I asked myself the obvious question: "What changed?" But there was no way to compare the state of the application before and after. [Full story at InfoWorld.com]

This column zeroes in on two ideas for making it easier to help people figure out what's gone wrong with their software: provenance ("Where did the error come from?") and configuration ("What changed?").

The length limit on the print column precluded a third idea: communication. In the case described in this column, I wound up installing a specially-instrumented version of a program that captured a trace, then gathering up that log file and transmitting it to the developer. Seems a bit arcane in this day and age, doesn't it? The following scenario should be entirely doable:

If the trouble ticket warrants such action, the developer determines which area of the program to trace, and at what level.
The trace specification is loaded into a service on the vendor's site, keyed to the product's serial number.
Now when the application runs, the specified debugging data are (with the user's permission) collected and relayed to the site.
Optionally a screencast (again with permission) is captured and sent.
If analysis of these data yields a new hypothesis, the cycle may repeat with a new trace specification.
If the investigation yields a solution, the user is informed and thanked.

That last step might be the most crucial. Where's the incentive, after all, to play the current version of this game -- that is, to agree to send your core dump to the vendor? Your report just vanishes into a black hole. You never find out what use was or wasn't made of the data you contributed, and there's no ongoing involvement. If the game were instead structured according to the architecture of participation, a lot of folks would get a kick out of helping to improve their software, irrespective of whether that software is commercial or open source.

Former URL: http://weblog.infoworld.com/udell/2006/08/23.html#a1512