Mobile development guide: Testing, requirements and security
A comprehensive collection of articles, videos and more, hand-picked by our editors
Software teams don't pay enough attention to the performance management process. In fact, they don't see it as a process at all. Instead of architecting apps to run fast from the get-go -- and coding and testing them with performance goals in mind -- they take a wait-and-see approach, hoping the software won't run into trouble when in production.
When the inevitable happens -- poor performance -- operations managers rush in to find and fix the bottlenecks. They are firefighters putting out a blaze without taking measures to prevent it in the first place.
Fixing performance problems after the fact is pretty much standard procedure for all applications. But mobile environments make the problem much worse. With users on the move among widely varying connectivity conditions, poor mobile app performance is so prevalent it's almost the norm. However, I think there's an upside to this situation: Mobile performance is so poor that software teams and the organizations behind them have no choice but to begin building apps better able to withstand the changing connectivity conditions that affect performance.
Mobile teams need to take application performance management into account early in the software development process, designing mobile apps for speed and simplicity. They can't control connectivity, but they can architect, code and test the app for optimal performance. They need to do everything they can to make sure they aren't making the problem worse.
What will it take to spur software teams into action? Pressure from business leaders, according to voke Inc. analyst Theresa Lanowitz. As she explained in a SearchCIO-Midmarket webcast, entitled, Application performance management can make or break your brand, mobile app performance is increasingly in the spotlight as customers' experience with mobile apps directly influences their perception of the company.
Mobile teams can't control connectivity, but they can architect, code and test the app for optimal performance.
In this installment of Quality Time, I discuss some ways to address mobile performance problems based on recent conversations with application performance experts.
Setting up mobile applications to automatically deliver developers info about the conditions under which the crash occurred is a good idea. Understanding the state of the battery, memory and CPU is key to replicating the crash, as well as to preventing it from happening again.
But does crash reporting solve the right problem? Sure, mobile apps crash sometimes, but more often, they sort of work -- or at least look like they're working -- but not well enough to be useful. Case in point: Last month on a visit to Manhattan I was on the street in Midtown using Google Maps to find an address for a restaurant. I stepped away from the crowd and typed in the restaurant name on my iPhone keyboard. Then I waited; and waited. The app was running -- at least it looked like it was running -- but it wasn't returning any info. Tired of waiting, I opted for plan B. I asked a stranger on the street and voila, he pointed me to the restaurant a couple of blocks away. From a user's point of view, the app had crashed and was abandoned. Shouldn't developers know this?
Error messages, anyone?
Error messages could help make mobile performance problems less annoying simply by letting users know what's going on. Releasing an error message along the lines of, "Can't access this service at this time…" is easy enough to do from a software development and test perspective. But from an accountability standpoint, it's another story. Incorporating error messages requires the software team and organization behind the mobile app to acknowledge there's a performance problem. That would be a step in the right direction.
Go on the data diet
Here's a simple step developers and project managers can take to improve mobile app performance: Think carefully in the planning stages about what data the app needs and provide only that. That's one suggestion Stephen Pierzchala, a technology strategist at Detroit, Mich.-based Compuware Corp., which sells tools for performance management testing, made during a recent conversation. "Pushing out massive amounts of data is no good for mobile app users when their connection falls back to 3G," he said.
Build in resiliency
Peirzchala's second suggestion is more challenging for software teams to implement because it requires buy in from the business leaders who own the app. He suggested turning off third-party services that mobile apps rely on when they aren't performing fast enough. "You need a fallback position -- turn off analytics; turn off ads." He calls this "building in resiliency"; it's not a perfect position, but it's better than allowing a slow-performing app or app shutdown.