I strongly believe that a distinguishing mark between a good app and a great app is resilience, or in other words, its ability to adapt to unusual conditions. Naturally, it's up to the app's architects and developers to make it resilient, but too often I see apps that break with the slightest change of an upstream API. This has been observed not only with small, relatively unknown apps, but also with some high profile ones, such as the official Facebook app for Windows Phone. Why is this behavior so prevalent? The way I see it, there are three separate causes, any one of which can create this problem: lack of experience, thoughtlessness, and (of course) laziness.

The causes

Let's start with lack of experience. This happens more to young developers, obviously, because they haven't yet had projects suddenly start failing on them for no apparent reason. Seasoned developers are guaranteed to have experienced this, and quite often due to a third party screwing up the APIs they are accessing. Unfortunately, not much can be done to alleviate a lack of experience aside from, well, gaining some experience! The more clever developers will gain experience by watching others fail and learning from those mistakes. The average developers will gain experience by failing themselves and learning from that. The below average devs fall into the second cause, thoughtlessness.

When people don't learn from their own mistakes, they are bound to repeat them. In the narrow situation that's being discussed here, I'm going to call that thoughtlessness. When architects/developers should be aware of potential issues (considering their experience), and yet do nothing about them, it's thoughtless. In fact, I would go so far as to say that they are bad architects/developers. I would not want to work with them. Or look at their code. I do not know if anything can be done with such people to make them better. If there is, I haven't come across it. And that's sad.

Now we come to laziness. Larry Wall famously wrote that laziness is one of three great virtues of a programmer. However, when laziness isn't tempered with the other two, impatience and hubris, it quickly goes from virtue to vice. I have occasionally been guilty of this myself. Sometimes, when I really want to get an app functioning, I'll forgo good techniques in favor of quick turnaround. I (usually) force myself to fix particularly bad code later on. Many others do not. When people release apps that were lazily coded, those apps should be expected to easily break. Sometimes small utilities with a very limited scope are fine to release without much error handling. They just aren't that important. But a public app that is submitted to an app store should never fall into that category. If developers are taking the time to release their apps to the public, especially if those apps aren't free, they must be resilient.

A real world counter-example

I must confess, the catalyst for my writing this blog post is that one of my apps has proven to be resilient this past weekend, and I realized that many others would not have coded it to be so. ArkWords, my free dictionary/thesaurus/translator for Windows Phone, has a popular feature called Word of the Day. It's pretty self-explanatory. What's interesting about it, though, is that I wrote a web service that sends a Live Tile image with the current word as well as the day of the week that's associated with that word. My upstream provider, the awesome Wordnik.com, has always released new WotD entries during weekdays, so the Live Tile for Friday would show "Fri/Sat/Sun" for the day because otherwise people would think something is wrong when it's Sunday and they're seeing the word from Friday. The app itself has a highlighted sentence at the top of the WotD definition stating, to which day(s) the current word applies. As you might have guessed, this weekend Wordnik, for whatever reason, decided to release new WotD entries both Saturday and Sunday. Both ArkWords and the web service handled this change perfectly. Obviously, "Fri/Sat/Sun" for Friday's word of the day wasn't entirely accurate anymore, but the Live Tile and the app displayed Saturday's and Sundays words of the day exactly as they should have, with proper day labels and everything.

I think this is a prime example of app resilience. I'm not trying to praise my own skills here. I only want people realize that it's important to make their apps resilient. Lots and lots of apps consume third party APIs. Developers and architects must be aware of the dangers associated with their use. How will your app react to an upstream change?