Fix Your Bugs
Most of you should be familiar with the Microsoft Error Reporting service. If you are not, this is a service that when an error occurs in an application running on a Microsoft Operating System, such as Vista, it offers to report the problem to Microsoft in order that they “improve” your experience. What’s interesting about this service is the data. They have undoubtedly gathered millions of errors over the years and have some pretty interesting insight into application errors. What I found most compelling is that if you only 1% of the bugs you will improve the experience for 50% of the users.
I’m not sure if this error / customer impact rate extends perfectly to Web 2.0 or Software as a Service applications but I suspect it is not off by much. If you don’t mine your application’s error logs, you’re missing out on a plethora of insight into not only your application but more importantly your users’ experience. Unless the error is coming from an offline process each error or set of errors is resulting in a frustrated user.
We’ve talked in the past about monitoring your application, how much logging is necessary, and not relying on your customers to find problems. Custom application monitoring such as with SCAMP is ideal. However, unless you’ve turned off all logging you should still have web and app server logs to parse through starting today. There are lots of open source log parsers such as AWStats or Webalizer or if you’re the NIH-type there is always the option of building something custom using MySQL or Hadoop.
Start today, looking through your log files for the top five errors and file bugs to have them fixed before the next release goes out the door. Make investigating log files part of your process especially after releases. Just simply the number of errors logged should give you some indication of the application’s performance compared to previous versions. Your customers will thank you for it.