iPhone 3G battery drain and potential code smell

When your iPhone is setup to use Push email update, it can drain your battery dramatically whenever the server becomes unavailable. This is clearly a design problem that should have been prevented. Applications should degrade gracefully, and similarly, they should enhance gracefully.

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.

Effective architecture documentation practice on a budget

In documenting Software Architecture, boxes and lines are the norm and they are nice, they can even be aesthetic. But unless they shed light on otherwise unclear semantics, boxes and lines can be wasteful. Architecture documentation is more than the diagrams, it concerns everything that bears knowledge of the system and can inform decisions taken.

Think of good practices in waste reduction, since you have scarce resources.

Use architectural frameworks as guidance to good practice, don’t bother creating all kinds of artefacts that nobody in your teams will miss.

Regular architecture reviews and code reviews will do much to ensure quality and share knowledge within your teams. Run them effectively.

Boxes and lines are nice, can even be aesthetic. But unless they shed light on otherwise unclear semantics, boxes and lines can be wasteful.

To be effective, your architecture models must capture and maintain essential knowledge about your system, this includes user stories and issue and feature databases, and source code!

When you’re clear on what your team should produce and maintain and the scheduling, then and only then look for cheap tools that can help.

Here is a take:

You can get away with a few simple documents:

  • screen flows: use a simple drawing tool, or scan sketches into image files
  • user stories (or use cases), it’s your software promise to its users
  • design principles, essential Do’s and Dont’s for your technical folks
  • design trade-offs, technical decisions and their limits
  • contracts (internal and external APIs for your modules)
  • business rules, the knowledge-bearing decision points in your system

In the list above, one can argue whether business rules should really be included in an architecture documentation. The same goes for screenflows and user stories. But when running on tight budget, decisions tend to be made on the flight and built into the code, people rarely go back and update otherwise stale diagrams.

User stories are created at the initiation stages, but over time they are superseded by the issues logged against iterations of the product. The features could change shape as a result of the learning process, to a point where the initial architecture might become significantly altered.

What happens is that, over time, knowledge increasingly migrate to the issue database and the source code, and it stays there. That is the rationale for considering the issue database as part of the architecture documentation.

Some tips:

  • Avoid waste: any document that doesn’t hold unique information is a waste
  • Be economical with the boxes and lines, focus on contracts and boundaries
  • Use spreadsheets to capture your architecture principles, trade-offs, business rules
  • Maintain an active issue and feature database. You would probably be doing this anyway, but I’m saying that consider it an architecture documentation artefact
  • Encourage in-code documentation, enforce through standard quality checking and code reviews
  • If your tool-kit permit it, (thinking JavaDoc) generate documentation from source code and include them in your code review sessions

There are more tactics for capturing and maintaining knowledge within your organisation, but that is perhaps a topic for another post.

Management lessons from recent headlines on Tiger Woods

I think the recent brouhaha on Tiger Woods’ private matters is a good test of leadership and management for sponsors and organisations involved with the Tiger Woods franchise. Indeed this is a good test of society’s celebrity culture and its many shortcomings.

I think the recent brouhaha on Tiger Woods’ private matters is a good test of leadership and management for sponsors and organisations involved with the Tiger Woods franchise. Indeed this is a good test of society’s celebrity culture and its many shortcomings. I was going to ignore all the noise, but I felt a short take on leadership and management lessons can be drawn from it.

Whatever might or might not have happened, the point here is that the involved managers should be asking themselves one simple question: did we hire Tiger Woods for his mastery of private affairs and gossip control, or did we hire him for his legendary golfing abilities? If the answer is the former, then by all means you have a case to sack him. If the answer is the latter, and that you’re concerned about the potential impact on your brand then clearly you haven’t done your homework.

If Tiger Woods’ brand is such an equity for a business, why aren’t such business around when Tiger’s brand comes under attack and needs support? This might not be a standard practice, but that would have been a show of good team stewardship. That’s the point I want to make here: people put up a team for a mission, but they are not around when team members need support.

So what is the management lesson take away from this saga?

Anything that contribute to your business should concern you all the time. This means that you should take care of it throughout, not simply leave things to chance and expect to milk rewards.

How does this apply to Enterprise Architecture?

It is more to do with leadership and team stewardship. When you lead a team, it is also your duty to support and protect your team members. In Enterprise Architecture endeavours, this amounts to embracing other (non-technical) stakeholders success as one’s own. If and when you do that, you increase the odds of successful outcome for everybody. If however, you only consider ensuring that there would be no flaws on your personal outputs, that might not be enough and you could be letting everybody (including yourself) down.

This will be an interesting test, we will see what happens in the end. If the big sponsors start deserting Woods because of his recent alleged personal problems, everyone could draw his/her own conclusions. I read a non-sense that Woods attacking celebrity culture was misguided as apparently they made him. I think that’s untrue. What made Tiger is his golfing prowess, many took advantage of it as they saw fit. Now some are eagerly calling for his head, I suspect because it sells their paper. No wonder some form of papers are under pressure with the advent of social media, if they can’t communicate properly then nobody would be listening. It is that simple. Like Peter Drucker put it, it’s the challenge of getting communication out of information.

Leverage the best of community and agile approaches for results

It is a good idea to leverage the best of communities and agile approaches to product development in Software Architecture practices. Last semester product releases from Microsoft are indication that they are applying these concepts, Architects should learn from that.

It seems to me that Microsoft is applying some valuable lessons from open-source and community driven software processes: get user buy-in as early as possible, deliver early and frequently incomplete or partially flawed products. People will happily participate, you would get a more accurate feel for the reception when the product finally ships. I don’t know what the pundits are saying, but to me (as a software architect and user), this strategy pays off handsomely.

Every new Microsoft product I laid my hands on over last half-year has been nicely thought out and clearly user-oriented by design. You can almost feel that product development received a lot of attention, and that is good news for the 90% of us who use Microsoft software.

I’ve started using Microsoft Office 2010 Beta on my Windows 7 box. You immediately see the impact of some of the lessons they’ve learned with the previous major release, the ribbon concept has been tweaked, the experience feels more natural yet innovative. I’ve not had to spend any time reading documentation (though that would be a mistake for a final product, reading the documentation is always for the best), I had no troubles working just like before.

Similarly, when I first learned about the early Microsoft Azure visions, I was having a strange feeling of “lipstick on a pig” treatment. After PDC2009, I saw lots of improvements and change of heart on some early ideas that seem to be, without a doubt, the result of extensive community participation.

The early concepts and beta releases of SharePoint 2010 and Office 2010 have stunned me in their clarity of vision, for the first time I’m getting excited about Microsoft’s web-based software. Having spent the best part of last decade delivering non-Microsoft solutions, albeit I’ve never lost sight of what they were doing, I am seeing a lot of good vibes coming from Redmont these days.

Another potential idea that can be read here, would be that Microsoft is directly engaging users and hence doing away with their former approach where their partners supplied the bulk of feature requirements (I’ve read a lot of Michael Cusumano and Mary Jo Foley throughout the years, any misreading would be mine).

To me, these are all signs that Microsoft’s products are improving, they are increasingly addressing unmet user needs. This would be a software delivery equivalent of a “growth business”, I buy it.

I see a parallel with the practice of software architecture, whether its Enterprise Architecture or Solution Architecture on a smaller scoped project. Software Architects can achieve much success by adopting some of the same recipes hinted at earlier, by no means a complete list:

  • don’t seek completeness on any significant topic before getting stakeholder communities fully engaged (no, they won’t think you’re daft)
  • don’t think you have all the answers (many thought leaders are saying this), actively seek and incorporate ideas from the receiving parties – they’d have a hard-time to reject their own input, wouldn’t they?
  • delegate major chunks to smaller and dedicated groups, see to it that the inter-group communication is fluid and sustained (I don’t know if Microsoft does this, it seems many of their products are still large silos).

With this type of approach, the outcome tend to feel much more natural and the acceptance will probably be easier. You see it for example when, using the product, you guess how something might work and could verify that the feature was implemented almost exactly as you guessed. This happens a lot when I use Apple products. I used to think that Microsoft would never be able to match such feat, but I now see that they are changing their approach for the better.