I've concluded that many software vendors (particularly large ones) don't understand how much support users of their software provide to each other, and how critical that support is.
The SQL and data communities are a good example of this. When someone has a problem and are wondering how to solve it, they don't call Microsoft or Google or Oracle (or whichever vendor) first. If they're lucky, they ask a colleague for help. But most will simply make a Google search (or yes a Bing search) to try to find an answer.
No matter how obscure an error message might be, if someone else has struggled with it before, at least there's a chance that on an online forum, someone will have spelled out what caused it for them.
Even cryptic values like app IDs in Windows that look like this:
{ADA41B3C-C6FD-4A08-8CC1-D6EFDE67BE7D}
can be matched to an error or an application that's causing the error.
Most of this happens without the vendor even being involved.
So one of my pet hates (which Microsoft have heard loud and clear on internal mailing lists) is applications that break this pattern.
Every time I have an error that says:
and nothing else, I want to scream. Even that's enough to get an answer sometimes. "Every time I click on XXX and drag the YYY, I get an error saying Oops. Something went wrong!" might lead to a posting that solves the issue but it's so much tougher when there's no other info.
A plea to developers:
At the time the error occurs, even if you don't know exactly what happened, you must know something about what you expected and what happened. Tell us something. No matter how cryptic.
Another related trend is where there is an error message but it's a GUID:
C3479B1C-B1F3-4404-8F3C-AFA00AA0FEAF
And we think: "Great. We have something to work with" only to find that the GUID changes every time the error occurs and is only meaningful to the support team at the vendor organization.
Please don't do this either.
Give us something repeatable that we can use to help each other.
Wonderfully, they put a log event in the server system log which is rarely exposed to the end user.. Usually it's got a core dump, so if you have your co-operation switched on, you stand some chance of collecting more info, but if it's off you have no chance. What I do Greg is try to recreate the error in a virtual environment where I can see. What services are active in memory… Usually it's two services competing to reserve the same memory address. But if you are here, you are in some really deep shit, and I agree Greg that a simple error code in the user facing message is not a problem for any developer to incorporate. I usually set a memory space that accepts a code written to it when a module executes. I dump that code to the user, so I know immediately which method was running when the error happened.. even if the error dropped in a layer that I wasn't controlling. On the restart, I read the space before I overwrite it, so I can tell if it's a bad shut down from which we are recovering or an admin forced event etc… It's a good habit which sadly is not taught to new budding programmers…..
Hi Neil,
I see it simply. At the time the exception happened, there should be **some** knowledge of what was expected and didn't happen. Give the user some chance to debug it.
Regards,
Greg