7 April 2011

Mobile myths: Development process and mobile apps

When it comes to development process,  why should “mobile” development be treated any differently? After all, you are developing computer software with all the challenges that this brings…

The myth of mobile development

There does appear to be a growing belief that mobile development is somehow fundamentally different to other types of development, such as working with web sites. This is not the case – it’s just another type of computer software and it is foolhardy to pretend otherwise.

Mobile applications are small pieces of software that require fewer developers to work on them – often they can be delivered by a single person working on a single computer. Mobile development is dominated by a large number of freelancers and small-scale businesses that can offer to develop applications while working for less than £400 per day. This has put larger-scale software houses and digital agencies on the back foot as they are unable to compete with these low daily rates.

The rise of these “one-man-band” development shops has led to the perception that mobile development should be cheap. It has also given support to the myth that mobile development is somehow easy and a single person really can produce and maintain a robust application from their bedroom. You don’t need to worry about stuffy old development process, and you certainly don’t have to devote time to formal quality assurance.

This approach may get you through a simple application, but like it or not, if you are writing code then you are involved in software development with all the challenges and risks that this brings. The idea that mobile devices are ushering in a new age of simple and cheap software development is a dangerous myth.

You always get what you pay for

If you try to cut corners in software development then you will always get an inferior result. A single developer working outside of formal process may be able to knock out simple applications, but they will struggle to develop and maintain anything robust over the long term. They will inevitably fall victim to problems caused by human error and the cumulative effects of design mistakes that would normally be picked up by development process and code reviews.

The launch of the iPhone kicked off a “gold rush” that encouraged people to move into development from non-technical disciplines or lighter web application platforms. Many of these developers are using object-orientated languages for the very first time so tend to have a limited understanding of the importance of good object design and the value of rigorous development process.

This mixture of corner-cutting and inexperience has led to mobile development communities developing without reference to the kind of best practise developed elsewhere by hard-earned experience. There seems to be little reference to the processes that streamline development and protect you against human error when building and releasing applications. Standard configuration management practices such as rigorous source code control, continuous integration testing and automated deployments are not being adopted widely.

This isn’t happening because the processes aren’t required – it’s happening in part because too much mobile development is being driven by inexperienced developers operating on very limited margins. It’s only once you develop a few battle scars that you realise how important build engineering and release management can be.

Under developed ecosystems

Even if you decide to start asserting good development process on mobile development you can be held back by the relatively anaemic ecosystems that exist on some mobile platforms.

Apple’s insistence on ensuring that all development takes place on their hardware  is a limitation, particularly when they do not offer terribly sophisticated tools to support development. Developers working with .NET or Java will have a wide range of frameworks to support processes such as continuous integration, regression testing and unit testing, while nothing comparable exists in the Apple world. Tools such as xcodebuild can be used to script iOS builds, but there’s nothing to help you automate and regression test regular builds .

It’s all software to me

“Mobile” development is often treated as a separated discipline to “web”, and I’m not really sure why. After all, to a seasoned old coder like me it all looks like software development. The applications may be smaller, the devices a little more diverse, but it’s all still code that needs to be managed.

Mobile developers often complain that the process of submitting applications to app stores creates a unique set of problems for them. Having to deal with different settings, certificates and manual processes allows human error to creep in and undermine an application release.  There’s nothing new about this kind of deployment hell – indeed, ideas around build engineering and release management were originally developed to manage these challenges from the 1970s onwards.

The rise of mobile applications means that we are returning to a mode of development where the end product is a discrete, distributed application.  This is how things worked when I first started working in development and we had to devote a lot of time to ensuring that the building, packaging and releasing of software was a robust and largely automated process.

There’s nothing new about mobile applications and nothing different about best practice in terms of building, releasing and deploying. It’s  just that developers need to learn a little best practice and environments need to evolve so they can support it more readily.

Filed under Development process, Strategy, UI Development.