Tough Catch 22 with end users

Question

I've developed an automated crash reporting system that sends in realtime (via email) any issues that happens to the end user's application, I get all the details (e.g. which user, which class/method, etc.)

This is great, and even the crash reporting system has a secondary crash report system for itself (in case it fails) which writes to a log file.

On the plus side, I'm alerted to bugs faster than clients/users can call in; in some cases I've resolved bugs before they have even called in.

My problem is when to pass this information back to the client and how much to pass back. On one hand it's great that it exposes the bugs, but at the same time that's just the problem! Are we shooting ourself in the foot?

If we tell them we might get a negative response, and if we don't tell them we might get a negative response!

Please advise!

Answer 1

Fixing bugs before the client notices is a very good thing. And even if you can't fix a bug that fast, answering your client that you are already aware of it and working on it is good.

And remember that what matters most is to have software that "sucks less at every release".

Answer 2

I think you should tell them. Communication of bad news (e.g. "the bug will be fixed in the next release in 3 months' time") is better than no communication whatsoever.

Answer 3

If your application has a "status messages" type feature... just update that when a major issue is resolved... or you want to inform them that a major issue exists...

e.g.

"Billing system is being rebooted - est. downtime: 15min"

"Billing system is back up - 13:54 July 17,2009"

The end user will often not care why something isn't working, just that "IT" is aware of it, and there is an estimated time when it will be fixed.

so "null pointer exception in Client Module fixed" is pretty meaningless... but a note like:

"The 9:30am Issue with the Client search screen has been fixed. - 9:47am"

Answer 4

I am hoping you informed them that the application sends external emails in that way, since not informing of that commuication mechanism existing would be dubious at best.

In terms of informing the client, you can adopt a statisical approach, since they can be lent to support any case, e.g. how many bugs were fixed prior to the support call etc. But ultimately a pro-active approach with open communication can be a better policy than telling them as little as possible etc.

That then goes into non programming related matters, about client relationships, establishing a relationship of trust and respect, expectation management etc.

Answer 5

The altruistic thing to do would be to tell them everything. But honestly, that isn't always what the best thing to do is, in terms of making your job easier and keeping people happy.

From my time in IT, generally the best rule was to give them the information if they ask for it, but not to volunteer it otherwise unless it will negatively impact them in the near future(i.e. downtime). That way you don't upset anyone who wouldn't care otherwise, and those who are already upset you can offer the information as a peace offering.

The general rule of thumb is to basically keep a low profile and don't go poking things/users that don't need poking.

Answer 6

Be honest about your bugs, and honest about how and when they've been fixed.

Being honest about your bugs will be an incentive to you to keep your product stable by improving your QA process. This should result in a more stable product, and clients thinking of your product as more stable.

Being honest about how and when bugs have been fixed will improve your image with regard to client service and responsiveness.

Answer 7

The way that my company handled it, is that we had for all of our raise errors in stored procs, validations and such... error codes. These were mapped to a table in our database via the PK. Then we had two text fields, the user friendly version, and the technical side.

You could do something similar, or have your exception handling wrap a more friendly message, log it to the database, and give the user a reference code if they need to refer to it.

In the end, I think you are doing better now than just not having anything happen.

Answer 8

The usual solution is to let the user decide. Instead of sending the mail automatically, just ask: "Sorry that I just crashed. I've collected all the information about the problem and I could send it now to the developer so the issue can be fixed. Send? Yes/No"

Also prominently display the data that is being sent so that the user can make an educated guess what he should do.

[EDIT] You should be aware that most users will be very unhappy when they find out that your application calls home without telling them, especially when it sends a lot of data that the user might not want to see go out.

If your error message contains private data, you can be sued for computer fraud.