As a kid, Halloween is about as good as it gets. You’re allowed to wear whatever you want, no matter how ridiculous, and then go around your neighborhood and demand that adults give you candy.
Halloween is nothing short of institutionalized fleecing of the adult population by children.
For years I had the same routine when it came to Halloween.
Firstly, I would put on my carefully prepared costume and meet up with my friends and compare who had the best costume…
Then we’d all work diligently for several hours to systematically knock on as many doors as possible.
Once finished I would part from my friends and rush home to count and sort my plunder. Ahh the glory!
My system of counting and sorting was very specific. The individual brands of candies were put into small piles which were then grouped into bigger clusters of like types of candies. Chocolate usually went on one side with everything else occupying the other.
I have recreated my method below.
Something I remember particularly hating on Halloween was having one of my favorite types of candies disappoint me. I worked hard to collect as many of the ‘good kinds’ of candies and avoid the apples and toothbrushes (yes some adults are that cruel), the last thing I wanted to see after sorting my candy was a candy defect.
Occasionally my Halloween candy would include a bag of m&m’s that had too many brown ones and no green ones…
Other times a lolly pop came pre-smashed….
Sometimes a Reese’s was already half unwrapped…
Or maybe a Jolly Rancher would come without any candy in the damn wrapper!!!
Whatever the defect was, it stunk, and I hated it.
What are three ways crash reporting could help these candy defects?
When I was a kid my favorite Halloween candies were made by the fine people at Hershey’s. Their candies are delicious and very easy to use. I remember growing up a very satisfied Hershey’s candy user.
Despite my overall happiness with the Hersey’s candy user experience, the errors I listed above did upset me as a kid on Halloween.
Unfortunately for Hershey, the only way they could ever know about my user problems is if I had complained directly to them. To do that I would had to take a picture to record the event. I would then have had to mail or email my complaint directly to their candy developers or candy quality assurance folks.
What a hassle!
Obviously I never mailed in my complaints because I was a normal candy user, and I, like most candy users, kept my complaint to myself. When I encountered a problem I just started leaning a bit more towards Mars products, starting to favoring Snickers over Reese’s.
For the most part your users are like this as well.
Most of the time that your users experience a defect they don’t report it. BUT just because they don’t report it doesn’t mean that the defect did not affect on the way they view your product.
There are occasionally users that do report problems, but they are generally exceptionally tech savvy, actively searching for a solution, or are just the kind of user that enjoys complaining.
Either way these users are not representative of your entire user base and this process of reporting is not quantifiable or scientific or efficient.
You need to implement a system for tracking every user crash in order to improve the feedback and information you get from your users when they encounter problems.
Without this kind of system in place several serious questions remain for how well your application is performing.
Questions Hershey’s could answer with crash reporting in place:
1. What candy defects are occurring most frequently?
2. Which candy defects are causing the most problems in Hershey’s candy eating install base?
3. How can Hershey accurately replicate their reported candy defects so that their candy developers know how to go about fixing them?
If Hershey’s were a software company they could easily figure out the answers to these questions by integrating a crash reporting tool into their shipped products.
This would benefit their candy in three major ways.
1. Using crash reporting Hershey’s could tell which candy related defect was being experienced most frequently by their millions of candy users.
2. Hershey’s could then use this information collected by their crash reporting tool to quickly and efficiently find what is going wrong and fix it. With crash reporting tools it’s trivial to determine exactly where your program crashed.
3. Finally, Hershey’s would never again struggle to replicate an error experienced by their users. Crash reporters give you the exact record of the crash. No struggle required.
I don’t have a great suggestion for how Hershey’s can implement a candy crash reporting tool (maybe partner with a customer complaint mobile app – 6 Mobile Tools for Managing Customer Complaints), but it is relatively easy for you to get this kind of user data for your software, game, or mobile application.
The simplest way to do this is by integrating a crash reporting tool into you application before you ship it out to your users. Crash reporting can also be added during an update. Usually integration is as easy as copying and pasting a little bit of code.
Once integrated crash reporting tools allow you to track all instances of your user crashes. That allows your team to see which ones are causing the most problems and which should be labeled critical and addressed now. They also cut down on the overall time it takes to fix bugs because they can point to the exact line of code where the error occurred.
If only my candy had the ability to add crash reporting… Luckily you do!
If you’re interested in crash reporting for your video game or desktop application I humbly suggest that you check out the software crash reporting solution for C++, .NET, Java, and OS X at BugSplat Software (my company).
Here is an overview of other services that also do desktop crash reporting.
If you’re looking for an exclusively mobile application crash reporting solution we suggest that you take a look at this wonderful SlideShare.
Thanks for reading this little bit of silliness.