Creating a considerate software
I read Jeff Atwood's post on how to handle software errors, and I agree with the concept of not harassing the user with useless error dialogs (while writing the error in the log file, of course).
After reading a related post on considerate software, I was a little amused to read this comment to the first post:
"Network BDE/Paradox apps corrupt data all the time - it's our number one cause of support calls. I'll be glad to be rid of it."
During one of the previous jobs, I worked at a very small account software firm.
The application was written in Delphi, using Paradox as a local (tabular) database.
Paradox is a great database for small application, since it's very fast (especially compared to Access, the main competitor in that scale of uses), but it's table get corrupted sometimes (mostly from using it across network drives or from unexpected shutdowns).
Most of the times it's not an actual data corruption, but index/header corruption, in which the table can be safely rebuilt.
So I found a library specializing in Paradox table repair, took the time to study it, and added a mechanism during the application start up to automatically verify the database and fix it if needed.
Only when the failure of the data was catastrophic I notified the user, and even than a possible solution could have been daily automatic backup (I can't recall if I implemented this feature).
This feature reduced the number of database related support calls by 80-90%.
So if the commenter is still receiving many support calls, I'm not sure his software is very considerate.
No comments:
Post a Comment