12 Feelings Every Developer Has After Introducing an Error to Production

 ● 10th May 2018

3 min read

Waiting for your code to compile? Trying to find the root cause of the current issue you’ve encountered? Here are a few Gifs that can help you cope with the situation

Picture the following scenario. It’s Friday morning and you’ve just sat down with your hot cup of Java, ready to write some code. you fire up your environment, and suddenly you receive a call from support.
1. Something is wrong with the last deployment, and the call center is flooded with complaints.
2. Denial kicks in, you think you had everything under control, only to see that you’re wrong
spock frustrated
3. At this point, you go through the logs trying to find what happened in the code that made an exception to be thrown
4. Which, if you ask us, looks more like this:
5. At this point, you try to remember that the most important thing you need to do is keep calm and debug on
burn computer
6. You find (what you think is the) root cause of the issue, apply a fix or a workaround, deploy it and hope it’ll work
7. And usually, you’ll have to go deeper into the logs to try and find the actual root cause
bojack hammering
8. But what happens if you didn’t take the time to log the issue in the first place?
computer crash
9. And now you just don’t know what’s going on
what reaction
10. It’s getting late, and at this point, you realize you’ve spent half of your workday trying to track this one issue
11. Or you do manage to find and fix the issue in your staging environment, but production is a whole different story
debugging the code
12. And remember, it IS a Friday. Deploying a fix might lead to you losing your weekend keeping track that everything is working as it should

There must be a better way, right?

And there is, Kevin!

Let’s start with the basics – log files… suck. Counting on them to find issues in the code is like… counting on the cats to not push cups off the shelf.
To be more specific, at least 20% of exceptions that occur in production will never make it to the logs at all. Add on top of that the fact that 63% of logging statements aren’t running in production, and more than 50% of logging statements don’t include ANY information about the variable state at the time of an error. Yikes.
Why is it so important? If not caught in time, these issues will affect your customers and users. This could lead to frustration, complaints, and angry tweets, and your team will have to spend 20% of their work week trying to find what went wrong and how to fix it.
Instead, you want to focus on building a reliable product and improve your developers’ productivity by cutting down the time it takes to detect the root cause of issues. And you’re not the only one that feels the same, companies like TripAdvisor, Intuit, Comcast, Zynga, and others have also made the shift towards product reliability, by automating their error resolution workflows.
In return, these companies were able to cut down days of identifying and solving production errors to mere minutes. If you too want to add valuable automation to your workflow, you can read our complete guide to root cause analysis, here.

Henn is a marketing manager at OverOps covering topics related to Java, Scala and everything in between. She is a lover of gadgets, apps, technology and tea.

Troubleshooting Apache Spark Applications with OverOps OverOps’ ability to detect precisely why something broke and to see variable state is invaluable in a distributed compute environment.
Troubleshooting Apache Spark Applications with OverOps

Next Article

The Fastest Way to Why.

Eliminate the detective work of searching logs for the Cause of critical issues. Resolve issues in minutes.
Learn More