|
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.
|
NEWS 
