Oops, something went wrong…

A while back this post of Jurgen Appelo caught my attention.

When something goes wrong you have every reason to be annoyed. You are just about to do some task and the application you are using crashes. And what is that “something” anyway? Here, eat a maggot.

Although I am not the Product Owner of our team I will take responsibility and happily eat the maggots for any “Something went wrong” page that you see in Jortt. (one restriction is that the maggot should be made of chocolate, preferably sea salted 🙂)

You see, “Something went wrong” pages are a necessary part of software development. You can’t account for all possible failures that can happen upfront, one reason is that you simply do not know about all of them. There are just too many ways that can fail when it comes to software development. And, as I learned over the years growing a system from 50 to over 80000 users, everything that can go wrong will eventually go wrong.

“Something went wrong” is there for these use-cases. You account for a finite set of possible errors and then you have the “catch all” clause for the rest. If that happens we present to you the infamous “something went wrong”.

Looking at the Jortt error reports we got over the last couple of years we have had a few of these errors. In our case these were caused by:

• Most of them (I would say 90%) were simple errors like:- Null Pointer or type errors- Browser versions
• The rest mainly due to integration with third party providers doing unexpected things like:- Accidentally throwing away all of our data- Unique ids being reassigned to other entities- Data or format changes in an API we don’t know about

What happens when something goes wrong?

Whenever this error pops up our development team is automatically notified. Since we have a zero bug policy when it comes to these kinds of errors (not all bugs are equal) we immediately drop what we are doing and start fixing this bug. This can be either showing a better error message, or handle the unexpected thing appropriately. Since type and null errors are typically easy to fix, we deploy the fix within an hour most of the time.

After the fix is deployed we fix our process and try to ensure this does not happen again (it will of course). This can be done for instance by adding more tests and looking for similar code to check if it is vulnerable to the same error.

Error handling is a complex thing in software development. Especially when it comes to errors not caused by actions of your users, but by your own application. In these unforeseen cases we still present the user some sort of error message and fix the error as soon as possible. And eat a sea-salted chocolate maggot when we are done.