Recently I’ve been annoyed by an issue with my iPhone 3G, a phone I’ve had since August 2008: it’s battery was draining super fast and I didn’t see why this was happening. The battery life has never been stellar, but it also has never been this bad.
As I tweeted about this problem here, a friend of mine pointed out that this could be due to Push update when the server is not available, tweet here. He was right, as soon as I disabled the faulty email account, the battery issue stopped.
My problem is solved, but I’m not happy about what I think might be the root cause of this issue. I think I’ve bumped into a code smell, the like that architects ought to prevent for a pleasurable user experience.
When you think about it, the main reason that Push would drain battery life is that the phone would be continuously probing a non-responsive server, trying to reconnect. This would be mindlessly going on for as long as the problem persists, and that is precisely what I find troublesome.
A mobile service that is likely to experience connection problems, as a matter of fact any connected application, should have intelligence to space out the retries and give up after a reasonable amount of failed attempts.
When a server becomes unreachable, the device should stop trying and provide a feedback, visual or not. This enables the user to decide on an appropriate action or none. But I don’t see why the application would persist and keep trying again and again, until your device runs out of battery.
Looking at it from a coding perspective, there are two possible scenario: (1) someone decided to approve this functionality, or (2) it was overlooked.
In the second case, (2), this would qualify as a “code smell”. Such code smell could easily be remedied by simply introducing a variable and increasing retry interval, aiming to both reduce the number of attempts and giving it sufficient time to fail gracefully. An example such algorithm could be based on Fibonacci numbers, see Wikipedia, reducing the chances of mindless retries.
Naturally, for a company as large and reputable as Apple, this can hardly ever be a case of technical competence issue. They probably won’t even heard of this posting, or if they did, they probably wouldn’t care.
A big take away is that, it’s the tiny deficiencies of this kind that can accrue and potentially result in an overall poor user experience. At the end of the day, even if you have a nice architecture, you would be failing your users if you didn’t pay attention to tiny code smells with huge potential impact.
For a good user experience with connected applications, an architecture principle could be: degrade gracefully; after a reasonable amount of failed retries, stop and notify user when a server becomes unreachable. As richer features become available, gracefully enrich the user experience.