In an earlier article we pointed to a comScore study which found that sales of Android handsets are outpacing those of Apple’s iOS (along with those of every other smartphone platform). This is happening both in the US and in Europe. More Android handsets sold, more market share for Google’s platform, you’d be forgiven for thinking that both consumer and developer interest are leaning decisively towards the little green guy.

But it’s not that simple. As Erik Slivka points out in his June 7th piece in MacRumors, developers are overwhelmingly opting to develop for iOS, despite Apple’s lower market share. Slivka quotes Flurry Analytics, which issued a report cited in his article, stating “Android delivers less gain and more pain than iOS … the key reason seven out of every 10 apps built in the new economy are for iOS instead of Android.” Apparently, of 18,000 SDK downloads by smartphone developers in Q1 2012, 69% were for iOS. The key reason appears to be the extremely fragmented state of the Android device space. With multiple handset manufacturers, an endless proliferation of models (and screen sizes), and with operating system updates having to go from Google to the handset manufacturers to the providers before they get to the devices, most Android handsets are two or three major revisions behind the latest Android 4.0 Ice Cream Sandwich update. Scroll down to the end of Slivka’s piece to see that as of his writing, only 7.1% of Android phones were running the latest software. Contrast this to Apple’s installed base of iOS devices, 75%-80% of which were running that platform’s latest update: iOS 5.

The fragmentation problem is not merely statistical or academic. In Michael DeGusta’s excellent analysis from October of last year, he points to the constraints faced by developers writing software for Android phones, “most app developers will end up targeting an ancient version of the OS in order to maximize market reach.” Fewer apps and less investment towards Android on the part of developers translates to a more limited selection of worse-performing apps in the hands of consumers. DeGusta adds that those consumers are likely to be less satisfied with their phones to begin with, since most of them are running outdated versions of Android. This also impacts the expectations and “culture” of consumers on either side of the divide. iOS users expect more from their phones and their apps, but they’re also willing to pay more for that refinement.

At Waverley, we’re continuing to see interest in both Android and iOS on the part of our clients, and more cost-conscious clients are increasingly asking us to develop cross-platform apps using a single code base in HTML5. We might talk about the tradeoffs of such an approach in a future article. For now it’s clear that while Android pushes more handsets, most developers feel that iOS is where more money can be made.

CIO magazine published this article, Keeping the Cash: IT Leaders Can Slash Costs which recommends steps to reduce IT costs. One of them caught our attention:

“Halt the development of certain projects temporarily or permanently. If any of these projects are outsourced and your paying the outsourcer for time and materials, stopping the project, even for just a few months, can immediately save you money.”

This may make sense in some cases, but I can’t think of too many. From the perspective of working on high priority mission-critical projects, stopping randomly in the middle of development makes no sense because there is as much or more to lose as there is to gain. Firstly, If you’re working with great people, they will not sit around and wait for you – they will move on to other projects where their skills are useful. Outsourcers can’t afford to leave top talent stagnant for months at a time. Secondly, when you’re ready to get going again, you’ll have new knowledge transfer and ramp-up time issues to get through and this will push out the end date more than just the several months you chose to postpone work.

Here’s a better way to proceed. Rather than stopping and starting, look at your project and focus on delivering value as quickly as possible. It’s pretty well-accepted that many features of a large IT application are not going to be used and not all features have the same value to the organization. Divide up your features, prioritize each feature, then implement the work in small steps and have the project stakeholders evaluate the results at the end of each small step. Be willing to change priorities to match the organization’s goals. This is classic Agile development at work. At some point, you’re going to conclude that you have enough of the project done to meet critical needs and you can stop development and deliver something useful, rather than stopping development with little or nothing to show for your investment to date. It makes a lot of sense for a lot of reasons to keep development teams running smartly towards useful goals unless there is a significant mitigating factor. To get the most from your partners and your investment don’t let your project run on autopilot until a crisis occurs. That’s one way to avoid having to halt all development mid-stream, before you have something to show for your hard work and hard cash.

This article  from eWeek discusses the results of survey from VanDyke/Amplitude that found a larger number of network intrusions at companies that outsourced tech jobs. There aren’t a lot of details, unless of course you go and get the full survey, which I don’t have access to. If I were to guess, I would say most of this comes from the requirement for such companies to open network access to their company’s internal network. This of course is fraught with a variety of security issues that I suspect many companies aren’t taking seriously enough.

There are a few ways to mitigate against these kinds of risks. Here are a few ideas:

1. Choose an outsourcing partner that has lots of experience working via VPN and SSH with their partners. Their experience can help you ensure the right steps are taken. They will also be able to demonstrate how their own internal networks are kept secure.
2. Another option is to find an outsourcing partner that has their own secure network and services distinct from your own corporate network. The best partners have great capabilities for securely working with you without the need to access your internal network. You can then sync work at periodic intervals without full VPN access.
3. Specifically contract a network security specialist to assist in setting up access to your internal corporate network.
4. Isolate access to the networks and services your outsourcing partner needs. Keep these separate from what your internal people use. This might not be practical in many cases, but it could work in your case.
5. Use SSH with public keys as much as possible. It is as secure as a VPN, but offers many advantages to control access at a fine-grained level.