Learning To Fail Gracefully

A while back I wrote about the beauty in failing. It's almost like an art really. And it's unavoidable. Things will fail regardless of how aware you think you may be of the situation. Much in like The Matrix, things need failure, otherwise the program can't run and will collapse into a singularity of some kind. And this has a very real correlation in the "real" world as well.

Just imaging a website that you worked on that was perfect. Down to the last variable declaration. It accomplishes its tasks like no other project ever could. Where do you see yourself in the life of this project? You aren't perfect, so we couldn't very well have you adding your non-perfect code into this system. If a project was flawless, there would be no need for anyone to work on it and or to interfere with its mechanics. It would just sit there running flawlessly 24/7. But lucky for us, things fail and we get to fix them.

But there is a certain way to fail when software is concerned. We don't just let the chips fall where they will and call it a day. We make failure into a part of the entire process. Every step of failure should be as smooth as we can possibly make it. And that's what the remainder of this post is about. So read on, and fail.

Failing should be fun

Nothing looks more unprofessional on a website than a random confusing page with technical mumbo jumbo scrawled all over it, when all the user wanted was an image of a cat playing a xylophone.

Twitter gives an excellent example of an error page. It's fun and it doesn't just leave the user to fend for themselves.This is not a silent error. It's not confusing and it doesn't leave regular users wondering what went wrong in life. For these types of errors you should let the users know that everything is okay, that you will be back to your regular programming soon and more importantly, that your website knows what it's doing.

A colorful splash page will suffice for just such an occasion. Something that also used to be popular back in the day was to ask the user what they were up to just before the site fell into a vortex. If you're lacking traffic analytics, and can't recreate a user's path, then this would be a good approach. But not a permanent solution, which brings up my next point.

Don't ignore the problem

Always know what's happening on your websites. If there's a problem on your site, you should have somewhat of an idea as to what that problem is. There are many methods that you can use for this. I personally have my own custom logging library that I include in every project and I try catch anything that's too complex. Everything gets logged in my database and that falls back to a text file dump.

Whichever method you choose, just be aware of it. Have an email sent out to your support team, or to yourself, informing you that something happened somewhere that should not have.

Fail with purpose

When your site fails in some shape way or form, it should be a part of the process. Not a one off scenario that you spin off a new flow for. Keep your navigation in place and keep your tracking in place. Let the users know that this has been taken into account and that your "team" is on it. Link them to a support page, or a contact page and especially the home page.

Partial failure

We normally think of systematic failures as a whole entity. When your registration page fails, the entire page fails. But normally that isn't exactly what's going on. Every single line of code didn't unexpectedly come crashing down. But something in particular. Maybe the user entered an invalid zip code, or maybe the SendEmail code didn't run correctly due to a downed email server.

For the most part, any single function running in some software will be comprised of multiple pieces of functionality. An important question to ask is whether there are any pieces which can run without the remaining ones. For example, if you're creating an order for a sale, can you create the order and the user without needing to create a transaction record. More than likely, you can. Can you finish the transaction without sending the user an email receipt. You probably could. But the user does not need to know that your site is having issues.

So it's important when designing your code, to do so in a way that allows for flexibility in errors. And breaking your code down into as many pieces as possible will achieve just that.