Getting feedback from your users is an incredibly important part of the development and support process. However, traditional methods of learning about your critical defects are often not sufficient for producing great software.

User-reported bugs can get delivered in many different ways: emails to your support team, posts to your support forum, angry tweets, issues posted to GitHub, random posts on stack overflow.

All too frequently, users just ignore the defect and move forward as best they can.

However, if your goal is to find viable fixes to real bugs as quickly and efficiently as possible, then counting on your users to report when they run into bugs comes with some real trade-offs.

#1 User-reported bugs are short on actionable data

Users kind of stink at providing information that makes tracking down crashes easy for you. User-reported issues often focus on how frustrated they are, and the thoughtful reports can still easily not miss including data that helps you figure out what went wrong.

The best way to fix a bug is to have it captured locally in a debugger. This provides the data that helps you identify what went wrong. When was the last time a user provided you with the source code line number where the crash occurred?

#2 User reports are not an excellent early alert system

As hard as you try, there are going to be bugs that get shipped to your users. It's a reality of developing software. There's too much complexity in modern development to avoid having unexpected crashes affect your users.

If you wait for users to report that this is happening, then you've lost the ability to fix the issue before it becomes a problem for your broader install base.

#3 They don't help you measure frequency

Looking at user-reported bugs isn’t an accurate way to measure how often your application is crashing. All you can really tell is how frequently your users are reporting your problems. This may be proportional to how often certain crashes are happening—but then again, who knows?

#4 Reporting is removed from the event

When you rely on users to report their bugs through email or online forums, there are multiple steps between them and providing their feedback. This makes it less likely that they will actually report the issue, and it affects the reliability of the reporting because time has passed since it happened.

#5 It's a bad user experience

Manually reported bugs are already such a headache that your users went out of their way to report the problem. Ideally, you'd be able to save your users from this pain by getting early warnings before a bug becomes a real issue for your users, allowing you to push a fix before a bug becomes a real problem for a large part of your users.

What's the fix?

All of these issues create costly inefficiencies and add unnecessary tasks to your support process.

Luckily, they're also totally avoidable.

Automating the process of collecting data around crash defects—also known as crash reporting—fixes all of the above issues with user-reported crashes.

Crash reporting gives your team data on defects as soon as they start causing crashes for your customers. BugSplat even points you directly to the exact line of code which caused the crash in the first place.

The huge amount of data automatically collected by crash reporters dramatically shortens the time it takes to go from identifying a crash to finding the fix. You’ll have a new version released that fixes your issue before your users can start complaining about crashes and poor performance.

If you’re interested in trying out crash reporting for yourself, join the thousands of developers who use BugSplat to fix crash defects for over 250+ million of their customers every day.