Why not rely on user error reports

We at Parallels carefully analyze user error reports. We have an automated accounting and data processing system for this account. Specially trained people work with information and treat sores for users. However, not everyone shares our philosophy. Under the cut an interesting opinion of Nick Harley on the portal Medium. In the comments you can perfectly debate on a given topic.


')
We all love programming. Thinking about coding, we usually imagine that we are building something. We are building features, innovations, new functionality and great updates that users will like. This mental image inspires us to build the following things. But romantic pictures in our head are often not related to reality.

Software developers spend most of their time on tasks not related to creation. They meet, discuss specifications, plan and clean up the existing code. And, of course, their “favorite job” is to fix bugs.

I have not yet met a developer who would like to look for problems in their code bases. Probably, this dislike stems from the fact that searching and reproducing errors takes a lot of time.

Historically, developers are forced to look for needles in haystacks. They have to look for answers on their own, and not rely on screenshots that users send in Word files.



What browser version are you using? What OS? Can you tell exactly where you clicked? And then what happened? What page were you on before? How did you get on this screen? So many questions and so few (useful) answers. Debugging problems can take forever!

Relying on user error reports

Many development teams still rely on user reports. Today it is a real frenzy. It’s like in fast-food chains eateries asking visitors to clean up the table and clean the trays. Food can be terrible, but people obediently take their trays to the urns, empty them and leave. If no one complains, then the staff believes that everyone is happy. But people no longer return.

Some developers believe that users can take care of themselves when using their applications. If no one reports about problems, then they are not there, right? It is wrong to impose on users the obligation to report problems they encounter. Because of this, you will receive data on about one percent of all installed copies, and technical details will be scarce and inconsistent.

Developers will have to spend more time debugging, being content with bits of information than fixing the bugs themselves. If they can even find the root of the problem.

Your application is not as good as you think.

I once talked to a friend who works for a large online retailer. He told how they found a big problem in their online ordering system that nobody knew about.

After several days of proceedings, they could not find the cause of the problem. Then they decided to try to identify and diagnose errors in their applications using a separate tool. What they found was alarming.

It turned out that one of the eight servers ran out of memory and he threw errors. Because of this, the process of processing custom orders has completely stalled. One of the eight order processing sessions turned out to be a bat. Detection and resolution of this problem immediately led to an increase in sales of $ 20,000 per month! Customers no longer have difficulty with purchases.

The company estimated that the bug had an effect on approximately 5,000 users - but during all this time there were only two calls to the support service. This fact was a great disappointment, although the team was happy to solve the problem. The total loss of income due to the bug was about $ 100,000.

Sending a letter to yourself when errors occur is a foolish idea

You can sit and watch live in the logs for the flow of problems in your code. You can even hire someone to do it while you sleep. Or you can send yourself letters when an unhandled exception occurs - it seems like a great idea!

It seems as long as you do not implement it.

You can do something like this:

But this may lead to new problems.

It can be convenient to generate letters when errors occur on small side and personal projects. But as the size of the project grows, the situation will worsen. Severely deteriorate:

• Few details to diagnose.
• It’s hard to set up notification rules, so you’ll be overwhelmed by events.
• An exception caught in an endless loop can generate 50,000 emails in one night.
• Errors are not divided by priority or noticeable impact on users, they all look equivalent
• When you start receiving more than a hundred letters, you stop reading them.



Shortly after you start sending error messages, you will start to ignore them. Or filter in the folder, because there is a lot of noise, but there is little useful signal. You will have to sift through thousands of letters in search of the correct copy of the error. Need more intelligent solution

ELMAH - journaling exceptions

ELMAH (Error Logging Modules and Handlers) is an error logging plug-in. It can be dynamically added to a running ASP.NET web application, or even to all ASP.NET web applications on a machine, without recompiling or redeploying.

ELMAH does not support all programming languages ​​and platforms. Since its functionality is limited to finding the causes of problems, it is usually used in small projects. He is also not in a state of active development, but this is at least something. And it is free.



In essence, ELMAH is a NuGet package for .NET web applications. It logs in the repository of your choice all exceptions that occur on one or more websites. Unlike other similar frameworks, ELMAH automatic logs every exception, being configured in its simplest form. Of course, an API is available for logging specific errors, but many use only the automated part. Let's consider it.

Excellent getting started guide .

Separate tools for generating crash and crash reports

If you are serious about error handling and crashing your application, then use a specialized monitoring tool . This will allow you to automatically identify and diagnose problems affecting your users by adding a provider to your application code. Just a few lines of code.

This will help you:

• Filter out minor exceptions and focus on really important issues.
• Configure configurable notifications via mail, Slack or HipChat.
• Use one tool to track multiple languages ​​and platforms.
• Apply error grouping.
• Keep the entire team informed of errors and their solutions.



Such tools are not free and not cheap, but what time do you rate your time? Suppose you use a free tool. Then you have to distract from the code for a couple of hours to reproduce the bug. This is not a very good return on investment. Professional solutions help to significantly reduce the time to fix bugs, so that you can quickly return to the code and build improvements.

Even if you think your code is ideal, and users do not face problems, set yourself a good monitoring tool. You will be surprised at what he finds.

Be proactive and reap the benefits of this approach.

It would be great if technology automatically solved our software problems. Unfortunately, we are still far from such heights.

You can incorporate monitoring tools into your workflows to make it easier to fix bugs. But incoming data is often “polluted” and separated from the context in other systems.

The future of error monitoring is that all teams — frontend, backend, management, and support — have a comprehensive view of every problem that users encounter. And they could immediately proceed to its solution. This also applies to the upcoming trends in the field of continuous delivery and deployment. You can apply fixes and send to production within minutes after identifying the problem. No need to wait a week before deploying the next minor version.

Let your team handle errors and crashes of your applications. Detect problems before users, and do not impose on users the obligation to send bug reports. Because they will not do that.

ZY Parallels is a little different. How it all works, we wrote here and here .