Let’s kick this blog off with an analysis of an error message. That sounds fun, right?
Doesn’t matter. One of the most fascinating aspects of software development, for me, is how you’re holding essentially a time-delayed conversation with your users. Oh, and one of the participants in the conversation is a stunningly bad conversationalist with very limited responses.
That said, I don’t mean the kind of error message that we, as developers, like to see. I don’t mean the kind that is thick with information, stack traces, and various names of things we can go investigate. The ones usually emailed to us or logged somehow at all hours of the morning when we’re trying to sleep, or Friday at 5:00 PM when you’ve got something wildly more entertaining to do than chase down a bug. Usually. Of course, we’re all always thrilled (snark) to get these messages because of their delightful cornucopia of information.
No, the message I’m talking about is one that arguably has more impact on your software: the user-facing exception message.
I’m probably a rare individual in that I often read these messages start-to-finish. Multiple times. Partially because I’m greatly interested in what caused something I’m trying to use to crash. Mostly because it’s very enlightening, as a developer, to be put in the shoes of an end user for once. A user of a product that I had no part in developing. These are the messages that communicate when the transparent illusion of the program is shattered; and these are also the messages that should be held to a higher standard! After all, a user is presumably already frustrated by the time this message would even show up. Their program isn’t working! So it would benefit all of us, as developers, to take a long, hard look at the ways that we are communicating with our users (read: customers) in exceptional circumstances.
“This is a strange way to kick off a software blog,” you think. “Usually we’re building a small proof-of-concept app in a new tech stack in these kinds of blogs.” (Well, that has been my experience. Yours may differ!)
I can’t promise we won’t do that eventually, but this is a topic applicable to just about any project you work on. Ultimately, we will be communicating all manner of things to a user and it bears keeping that in mind as you handle exceptional circumstances.
Also, this message made me pretty angry and there is no better motivation for writing than anger. Probably.
So let’s finally look at it, with no further ado:
There you have it. A small amount of my desktop background, a command-line window, and one of the least helpful things I’ve ever read. Ever!
Some expository background: in addition to writing software, I’m a musician. I have a whole slew of tools for recording and producing. A digital audio workstation (hereafter: a “DAW”), an audio interface, all manner of cables, microphones, etc… Getting all of this to work nicely together isn’t usually so bad. But I had just finished up a new PC build and had to set all of those myriad parts up all over again. Everything seemed to be working according to plan and I fired up my DAW to begin my first project on a new machine. How exciting!
It immediately crashed. It pointed to the DLL in question – AudioSes.dll. Like any self respecting developer, I immediately consulted Google with various permutations of the full error information provided to me by the DAW. An important difference is that this error message did not explicitly ask me to search online for additional help. In fact, it carried with it much more information and even offered to report the crash with details for me. The average of all of the information seemed to be that I ought to try replacing AudioSes.dll because it was potentially corrupted. I should then try to re-register that and a few other things. What you are seeing is the result of attempting to re-register that DLL.
At this point, I’d like to introduce the idea that sometimes you can be provided with information that causes you to actually know less than you did before. Negative information. Not in the credit report or quantum sense, but in a much more mundane sense. I bring this idea up because that is immediately what I was confronted with when trying to better understand the kind of error that I was seeing. It appears that there are many paths that lead to this particular error code being generated. Many of them concerned an operation that I wasn’t even attempting! The sum total of the information I had received as a result of following the instruction to “search online” resulted in me having more questions than answers. I don’t think that’s a great outcome.
In fact, I would go so far as to say that I think this is terribly irresponsible. This error message, at the end, essentially gives up, shrugs and says “search the internet.” My problem with this is that we’re turning the first line of tech support defense over to random people on the internet, and trusting someone to filter out the signal from the noise. While it is true that most people answering the sort of questions that spring from this probably have a clear idea about what they’re doing, the fact is you, as an end user, do not know. I would liken this to having car trouble that causes you to look in your car’s manual and finding that their preferred method of diagnosing the issue is to describe the problem to a few hundred random people on the street and see if any of them can help you.
It may also be the case that the user that would see this message is already technically literate enough to figure out what they need to do by wading through all of the available information on the internet. The point is that you shouldn’t have to resort to that as the first option. This is an example of the breakdown of the dialogue on the part of the software.
Think of the exception messages as tech support, because in a way they are your first line of tech support. How would you feel if that was the caliber of tech support you received, right when you were the most frustrated? Would you feel better, instead, if it gave you a reasonable place to start and maybe an official source that explains just what exactly causes an error code 0x80070716? Maybe it could have even presented a more readable name than 0x80070716.
I should add that I don’t hold it against whoever wrote this message originally. I truly don’t. The world is awash with these kinds of things. I bet any one of us can bring up an example, from memory, of an unhelpful message. This one just happened to be the one I could remember most recently.
Anyway, you should pay very close attention to the way that you’re communicating with your users. You should especially pay very close attention when you are considering the kinds of things that could push your program into exceptional behavior and cause crashes. At the very least, allow this first line of tech support to give the user something more tangible to work with as they try to get back into whatever it was they were doing. Even if most people don’t read a lot of the communications flowing from program to user, someone will.
And then they’ll get just angry enough to write a blog post about it. Probably.