Mobitrends

This post has been on my mind for a long while, and even as I start writing it I know that this post won’t even allow me to dump a tenth of what I’ve had on my mind for a while now.

I’ve been doing or managing software projects for year now. Saw the rise of AGILE programming, saw people getting crazy about Test-Driven-Development… and yet I’ve rarely seen so much crappy software and such long development cycles in companies. Why ? Because Agile has become a method for hiding your responsibilities as a developer over a roadmap, a new way of crumpling  the whole development process where developers are empowered with everything while not given any responsibilities over the deliveries, a new way to fail project without consequencies.

AGILE is actually the less agile method I’ve ever experienced, where sprints are blind development tunnels where outside of the developers nobody can really evaluate how the project is progressing. With sprints lasting up to 2 months (I’ve seen it), and with no real ability o get anything delivered in-between, this is definitely the worst approach of all should you be a small-to-medium size company willing to deliver fast and iterate fast.

What are the real objectives for software ? In my opinion those points are a must and should always be granted

• The master branch has the current production code, and can be updated fast (after testing) should a bug be found. This is critical in my opinion : when a bug is found by a user in production : you must be able to correct it immediately ! And most of the time current methodologies just disable that from ever happening…
• No software goes to production before having been tested. An NO-UNITESTS ! Unitests are only good for testing complicated algorithms. You should focus on designing usage-based tests with scenarios following the most common user action suites. On the web, selenium is the way to go. And this is only going to enable you to limit regressions by highlighting potential side-effects of a latest code update that as a developer you may have missed.
• Deploy often. Why wait the end of a sprint to see a service update ? Some stories are fast to deliver and have limited impact on the codebase and can de done in a few hours… some require weeks of headaches… why choose your deployment speed to match the longest task development time ? Put each feature in a dedicated branch, merge them into testing when completed (for testing) and then into master for a final test run.

The Mobile world has been forever a very fragmented space. Nevertheless, now you can start making some real bucks there : Mobile Ads is taking off, Mobile apps can be sold in one-click app-stores and delivered to a big mass of user in a glimpse… The mobile world is getting mature enough so that we can safely say that 2010 is going to be the year of all brands and generally all software getting mobile.
Innovative brands and solutions providers have already invested (a lot) to get in the mobile, often taking expensive and unproven approaches to get into the mobile.
I still remember Fauchon’s gold and silver eclairs being sold in 2005 (!!) from the mobile and that we built at Kamayo (that was really ahead of the curve but it was an impressive achievement for 2005 o have a big brand such as Fauchon go that road)!

The decision process on how to build mobile application isn’t much easier now than it was in 2005 but a few ground rules have become clearer now :

• When working with a major brand, a communication agency or an operator in most cases you will be compelled in supporting a very large number of handsets. Those guys usually don’t like to push a message to their customers that only a fraction would be able to benefit from. At a proof of concept phase you may be able to limit to one or two platforms but you will need to should you’re able to scale and support all platforms.
• If you’re an indie developer or a startup, you should focus on making money. Today making money happens in those platforms in that order :
  iPhone, Android, Blackberry, Symbian, Windows Mobile, Java, Palm Pre
  You should address each platform one after another trying to do the best job you can so end-users see you care. More important than just developing a great app, you should spend time marketing it on the dedicated channels. You do *not* need to cover all platforms, actually it’s really a 80/20 strategy, most you money will probably come from the iphone or maybe android. So you should rather focus on one platform and do it perfectly than spend time on developing all platforms and not having the means to market them. From that prospective, Evernote is a perfect case to watch, they first did a cool iPhone app, then moved in a 1year time to android and blackberry and finally Symbian.

When it comes to massifying your production, it’s always the same story, either you use a tool to address all platforms or you use manpower. Both have pros and cons. Tools such as Streamezzo or J2MEPolish have become great over time but going for them binds your product to their IP and impacts your business model. This may not be acceptable in all cases and sometimes you may want to go in hidden areas where the tool may not go (yet).
In my opinion, manpower is a real option. There are lots of experienced developers and mobile companies out there that can help you reach all platforms at once at a relatively low cost. It all comes down to your ability of managing projects to make sure everything is on track in terms of time, cost and quality.