The demand for mobile application development has never been higher.
This year will see the number of smartphones exceed 1.8 billion worldwide and overtake PCs as the device most often used to access the Web, according to Stamford, Conn.-based Gartner Inc. Despite being a technology in its relative infancy, mobile apps carry a high level of consumer expectations. People don't just want a good experience, they want it now, and studies show that if they don't get it, they'll simply move on. Part of this "consumerization of IT" phenomenon means employees and bosses bring those lofty expectations to the workplace. In a recent interview with SearchCIO.com, J Schwann, founder and president of Chicago-based mobility strategy and application development firm Solstice Mobile, said companies need to be thinking about solving business problems with the mobile channel first to "gain efficiencies and fluidity within the business."
We asked three experts in mobility and mobile application development to weigh in on a critical question for CIOs: In this hypercompetitive space is speed to market more important than creating a flawless product? In response, we heard about the importance of changing the development culture, the game-changing potential of HTML5 and why testing can't get lost in the shuffle. The one answer all three experts agree on? There is no easy answer.
Quality and speed are both important, but changing the development culture is the key
"What trips up a lot of people is they focus on the technology and they miss the need to change the development culture. Because they do, even if they get the technology right, they don't produce a high-quality application that customers want to use. Then they wonder why they spent all this time and money for something that nobody's downloading because it only got a three-star rating." Jeffrey Hammond, analyst, Forrester Research Inc., Cambridge, Mass.
The short answer is no: Speed does not trump quality, especially in the mobile development space.
The reason for that is, particularly if you're building a consumer-facing application, the quickest way for your application to find itself in oblivion is to build something that gets a three-star rating or below. With 700,000 applications in the app store, there's hyper-competition for awareness and to be one of the 50 or 60 applications that actually gets installed in your end-consumer's device. There's nothing to knock you off that list like a suboptimal experience, and a quality problem will lead to a lower than four-star rating quicker than you can bet.
So, basically, when you release an application, you have to make sure it works as well as possible because with Apple's app store or Microsoft's applications store, there is a period of time you have to wait before the app gets approved. If you release something with a defect in it that even for one out of 20 users causes their app to blow up, you might be waiting a few days to a week before you can fix the defect. And during that time, your application's ratings are going down the tubes because those users who are frustrated are going to give you a low rating.
That doesn't mean that you don't go fast. You also need speed. When I talk to folks about how to do this, I always go back to the software "iron triangle": You essentially have money to spend, you've got a schedule to meet, and then you've got features that you want to build in. Basically, you can pick two of those, and you've got to vary the third. If you've got to be on a quick schedule and you only have a certain amount of money and if you want quality as well, then you've got to trade off features. That's why many companies will get to market quickly with a high-quality solution, but they'll do it with a minimum viable product. So, my advice is don't scrimp on quality but focus on the features that are most necessary to create some kind of connection with your customer. Once you've captured your customer, you can always add new features and update the application when you're ready.
One last thing: Depending on whether you're out there in the Web world or whether you're in the IT world, you can fall into either the speed trap or the quality trap.
The tendency to lean toward speed or quality depends on developers' backgrounds. If they're coming out of the Web world, they tend to focus on speed and don't think about quality. They're used to being able to quickly update their websites with nobody standing between them and their customer -- they can just go and put out a new release. So, this group tends to look at the speed and miss the quality trap.
For those who are coming from traditional IT, it's almost the reverse. They're used to having longer periods to test applications and to release applications. They may only put up two releases a year, and they're not used to needing a new release every time there's an update to iOS or a new version of Android comes out. And so they fall into the speed trap.
Demands for quickness and quality could be answered in HTML5
"Inasmuch as it tends to be situational, I do think the quality imperative will prevail. Whether it's for your customers or your internal employees, they're already consuming and experiencing interactions in a mobile environment, and there's the expectation of quality. That will bias things over time toward better work being done." John Jackson, analyst, IDC Research Inc., Framingham, Mass.
There are a couple of ways to consider this question. In a competitive situation, if your closest competitor gets to market and you're flat-footed and you don't have an app ready to go, then I suppose there are instances where things need to be slapped together fairly quickly. But aside from that, there is a certain expectation of quality.
Quality control regimes tend to differ across the platforms. So, there has been quite a lot written about less-consistent quality in the Android environment than what you get in the Apple environment. For developers, there are more hurdles and headaches getting your app approved for distribution through iOS; Apple is taking control of the quality. In the Android environment the onus is on everyone, from the developer to the mobile operator to the OEM to Google.
But in general, what we are seeing is that developers are increasingly taking a hybrid approach to application development. You have a universe of some 10 million-plus developers out there who are highly facile with Web technology, with HTML and HTML5 in particular, and the associated technologies. There is a lot of coding being done in HTML5, and then ultimately [the] adaptation of that coding to native environments: So, something like 80% of code is written in HTML5 and then you adapt it for native [application programming interfaces] APIs on iOS or Android or whatever the platform may be.
This has been a trend we've observed in the course of surveying developers over the past couple of years, where there's tremendous interest in developing using HTML5 just because it's sort of a lingua franca for a lot of the developer community. But ultimately, it has to be adapted to run on these native platforms. The benefit of this approach is that is you get a significant amount of code reuse across the platforms, but in the end you have to do some legwork to give it access to native functionality.
One might argue that the decision to use a lot of HTML in coding an app, as opposed to going the native route, is a sacrificial gesture to quality. In not developing natively, ostensibly you're giving up something in terms of performance and therefore quality in favor of code reuse across platforms. So, you know, it may be that apps writ large are not being all they can be because developers are making such prolific use of HTML5 before they ultimately extend these apps into native [APIs].
It's really subjective, but the matter remains that native development demands a certain skill set, a certain budget and a certain amount of time that not everyone has. Those three things can be an issue for even the largest organizations. And looking forward, I don't think there is any indication that we're going to see anything but heterogeneity for the time being. So, we're still going to get successive code drops of Android that are going to demand work -- and the same will be true of iOS and other environments. These environments are competitive among themselves, they compete on the basis of APIs that get exposed and on performance characteristics. As long that's true, we're going to get sort of an API-centric arms race, and that means the need to curate your apps over a lifecycle.
Beyond speed and quality, big questions revolve around testing
"Whether it's a Web-based application or a mobile application or a mainframe application -- that doesn't really matter. The risk -- what happens if it doesn't work right -- is what drives how much quality investment you make." Ian Finley, analyst, Gartner Inc., Stamford, Conn.
What surprises a lot of people is you actually have to do a lot more testing on mobile applications than on traditional Web-based applications. The reasons aren't hard to figure out; it's just that people are usually focused on the development of the application and not the testing part.
People truly underestimate how different mobile testing is, primarily because you now have to worry about the application working in more than a single kind of environment. If you're building for a browser, browsers are pretty much the same no matter where you are or where the end user is. But there are major differences in the way applications run, even within a product family. For example, in the Android product family, there are literally hundreds of different devices of different sizes, speeds and memory that can affect the performance, look and feel of the application -- all of which can lead to quality issues. Even though the code is executed properly, the customer may find the application unusable.
The other thing is that when you're building an application, typically you can depend on there being a network. But the nature of mobile is you might have four bars or you might have one bar, and that could change while you're driving down the road. So, the performance of your application and the look and feel can be adversely affected by bandwidth. And of course, the type of connection that you have also can change this quite a bit.
Read more about
mobile application development
Web performance testing can make or break your mobile sales strategy
Mobile application development: Fast, furious -- and flawed?
Mobile app dev meets agile best practices
When you put all those factors together, most companies realize they can't afford to test all the different situations their customers are going to use their application in; even testing a representative sample of them is going to take a lot more energy than testing for a desktop Web browser.
So, what should companies do? Testing should always be balanced against the risk. Take, for example, a consumer mobile banking application. It has to be very high quality -- you can't have people breaking into it. It's also potentially a big selling point for the bank, so you don't want it to perform poorly or be difficult to use. And, because you're building it as a mobile application, you probably have to support it on many different types of devices and operating system levels, and also have to deal with all the network issues.
In such a scenario you want do a lot of testing in development, typically using simulators. And then you're going to do testing on the devices you know most of your users use. You might do that in with your own test and development department or through cloud testing providers. Some companies will go a step further and do crowd testing. They'll work with a company that has testers all around the world, provide them with a test script and treat them like they were an employee of yours, and send you your result. And, if you're building something like a mobile banking app, you might have to do all of these tests to be sure that you've really covered all the bases you need to cover.
At the other end of the spectrum, you may have a very simple application you're planning to deploy to your employees on iPad2s because that's the only supported device and the app only needs to work when there's a good network connection. Here, you might not need to go beyond simulator or device-level testing, because quality requirements aren't as high and the complexity of the deployment -- who's actually going to use the application -- is much simpler.
Let us know what you think about the story; email Karen Goulart, Features Writer.