Software application development has had to embrace a ‘mobile-first’ philosophy for the road ahead. Smartphone and tablet sales have skyrocketed, web usage from mobile devices far outstrips that seen at the desktop level and mobile data channels are now reported to run with a heavier and more enriched stream of content than ever before.

For programmers this means a variety of things. Existing applications need to be optimised (or indeed re-optimised) for mobile; and this includes considerations from screen size refactoring to re-engineering for accelerometer usage, touch input, GPS-enablement and more.

Developing on a moving surface

Given the still-nascent state of touch, mobile-based speech input, constantly developing mobile form factors and (if we are quite honest) just about every other element in this dynamic equation, mobile-first is probably not best defined or addressed as a philosophy. Instead we need a methodology here incorporating aspects of Agile and other essentially iterative ingredients to allow us to “develop on a moving surface” so-to-speak.

The days of disconnected mobile and desktop development are not over; there are too many enterprise-scale monolithic development environments on the planet to break that mould. But constructing two separate code bases, in two distinct teams that are typically poorly connected and badly synchronised doesn’t make sense any more, if it ever did. Whether the target deployment is a web-based service or a native mobile app, a unified and truly dynamic approach is now a prerequisite.

Mobile needs to look to the web; this is the space where a state of “perpetual beta” is not uncommon and an inherent appreciation for cyclical reiteration of application code is an accepted fact of life. This does not necessarily mean developing in an environment where everything changes, but at least where a constant stream of change is brought to bear at a specified point in time and location upon the application surface.

Esoteric wildcard what-if development

Parallels with Eric Schmidt’s 70/20/10 programme come to mind where the Google boss has suggested a split of work targets to accommodate for constant change. In the software programmer’s universe this equates to a scenario where 70% of the code base should stay essentially the same, 20% should be focused on new project integration, then a final 10% exists as the “esoteric wildcard what-if” development factor, so that we can build for the unknown before it arrives. If this is indeed an element of an agile (and/or Agile) mobile first methodology, then at least it accommodates for a much needed insurance factor that may have been missing up until now.

But there is a caveat here for which we must draw a cautionary breath. Any mobile-first philosophy or methodology also needs to be hinged around a secure-first operational ideology. We only need to look at the case of HTC to see how dangerous a poorly conceived mobile development can be. The firm admitted charges of distributing insecure software and putting users at risk after the Federal Trade Commission (FTC) found that it had failed to properly train its developers or to comprehensively test the software it produced.

HTC actually ended up introducing security vulnerabilities into its software through customisations it had purposefully engineered. These vulnerabilities resulted in third parties being able to exploit sensitive information stored on users’ devices. Attempting to address mobile-first secure-first obligations now are programmes such as IBM’s MobileFirst strategy. IBM’s accepts that enterprise mobile today is an end-to-end solution responsibility that demands application design services with the requisite level of secure integration functionality. This truly is the only way forward.

So with mobility at the heart of our newest apps we can be pleased about the fact that connectivity is everywhere, but despite this truth, the prudent mobile programmer will develop as if there is “no juice in the pipe” and provision for a good degree of offline application functionality. Judicious mobile first development also accepts that there are a far wider variety of users of every type of application at any one point in time.

As mobile now grows further, development teams will need to act as close bedfellows; separating streams of work across different development platforms and/or operating systems will only result in duplication, disconnection and ultimately more chance of project failure. Aligning teams around application features rather than devices features can work out to be a progressively productive move here. Carrying those teams’ workloads through to delivering those features on iOS, Android, BlackBerry or Windows Phone can provide the end-to-end cohesion needed to succeed in the rapidly shifting mobile marketplace.

Features, functionality and form factor finesse

Ultimately, whatever approach a development team adopts it should embody a lean approach where application elements are componentised — or at least clearly defined enough to act as target mini-projects of identifiable functionality. Developing with speed as the primary objective (despite the transient and often disposable nature of mobile applications) is not the way forward. Features, functionality and form factor finesse should be our five Fs even if we don’t succeed in creating a new de facto mobile development methodology in formal terms.