How is the application lifecycle different when creating apps for mobile devices?
Requires Free Membership to View
When you register, you'll receive targeted emails designed to keep you informed of the most relevant information on Agile development, application security, testing & QA, software requirements, and more.
Hannah Smalltree, Editorial Director
According to the scènes à faire (stages to make) legal doctrine, if you give two reasonable authors the same idea, they will write the same novel. This doctrine has been applied to software developers accused of copyright infringement, suggesting that given the same technology problem, two reasonable developers would code the same solution.
So how is developing a banking user interface on an iPhone different from developing it for the Web, for a back office system or for a point of sale device? Of course we all want to say that they are radically different, that they need unique skill sets and that the problems are exceptional and requiring of rare and expensive talents. But the truth is that developing a solution in COBOL for the Mainframe or developing in Java for Android are mostly similar processes -- apart from two main differences.
First, the time frames are incredibly short for the development of mobile applications. Time-to-market in this fashion-conscious world is the main driving force, and every hour’s delay in delivery can cost millions in lost market share. Perhaps a unique feature of this platform is that revenues are generated in creative ways from software that tends to be free. Enabling those revenue-generating abilities is new to the development community, but is still just SMOP (simple matter of programming).
Second, the tools we use are constantly evolving, and the availability of off-the-shelf component pieces is unparalleled. However, there remains one serious shortcoming, and that is the availability of a common development platform that enables applications to be delivered to iOS, Android, BlackBerry, Symbian, Kindle, et al, in a write-once-run-anywhere way. Part of the reason for this is the lack of commonality of capabilities amongst the different platforms. Of course the platforms will become more and more similar, but some features will remain proprietary on some platforms and open on others.
The universal truth here is that despite all our advances in technologies and methodologies, we still develop software in the same way we always have. We start with a problem, we iterate through designs, we implement and refine, we exercise our solution and we deliver. What’s changed are the tools we use and time we have to get it done.
Like my boss once said, “You only have 1 and 0 to worry about – how hard can it be?”
This was first published in December 2011