Arc Tangent

Over on The Men­tal Fac­ulty Blog, Drew McCor­mack expounds on why he thinks native apps are here to stay. He doesn’t see native apps being sec­ond class cit­i­zens at all and his argu­ments are pretty cogent.

I’ll add this to his points though: good luck build­ing a HTML5 replace­ment for an app like Run­k­eeper. If you’ve not famil­iar with it, it’s an app for track­ing your run­ning — it uses the GPS to record your route, cal­cu­late your pace, and gives you updates over the headphones.

I can’t see how this app could be any­thing but native. Sure, you could build a webapp replace­ment that uses javascript to poll the GPS, but if your browser gets back­grounded, you’re not going to get the GPS data (unless, of course, Apple gives you an API to poll the GPS data reg­u­larly in javascript…)

Also: have you ever tried to do any­thing seri­ous with audio in javascript? It’s a mess.

Native Apps still have legs. In the future, we might be able to inte­grate webapps more tightly with our devices, but we’re a long way off giv­ing up on native.

I’ll admit when I first joined Pol­l­enizer, I found the devel­op­ment model a lit­tle scary. Pol­l­enizer uses (sort-​of, kind-​of) out­sourced devel­op­ment teams in for­eign coun­tries. Out­sourced dev teams tend to get a bad rap, often being described as being low-​quality, cheap and dif­fi­cult to work with.

At Pol­l­enizer, these aren’t such issues. The model is slightly dif­fer­ent though.

Instead of using elance or free­lancer or some sim­i­lar sys­tem to find devel­op­ers, Pol­l­enizer has a ded­i­cated team in India. They work along­side us on start-​up projects from incep­tion to com­ple­tion. They’re not robotic in any sense — we don’t just throw spec­i­fi­ca­tions at them and expect them to com­plete them. They’re com­plete par­tic­i­pants in the process; their sug­ges­tions and ideas are taken on board and more often than not incor­po­rated into the fin­ished product.

I work with four devel­op­ers as their “bridge” to Aus­tralia, and I think the process is a good one. We’re learn­ing from them; they’re learn­ing from us. Every project is mak­ing every­one involved in it sharper and more cre­ative. The biggest chal­lenge for me, as a devel­oper, has been let­ting go and learn­ing to del­e­gate rather than tak­ing every­thing on myself (I am con­stantly over-​enthusiastic; it is prob­a­bly my great­est pro­fes­sional flaw. I’m work­ing on it).

If I’m being hon­est, some of the “out­sourced” devel­op­ers I’m work­ing with are bet­ter devel­op­ers than I am.

I think the key here though is that these are not just ran­dom faces at the end of the Inter­net who I’m task­ing with work. They’re peo­ple I inter­act with on a daily basis (we com­mu­ni­cate con­stantly via Skype). I’m con­cerned when they’re sick. I expe­ri­ence a mas­sive kick when they do some­thing inno­v­a­tive. When some­thing goes wrong, they’re right in there beside me work­ing to fix it. They’re co-​workers in every sense of the word.

Any­one who expects to fling code at an out­sourc­ing com­pany — wher­ever in the world it is — is not going to get good results. Devel­op­ers every­where require men­tor­ship and team­work, peer review and guid­ance. Gone are the days of the lone hot-​shot devel­oper; we’re team play­ers now, and you need to build a team.

If you want to out­source your soft­ware devel­op­ment, you have to care about qual­ity, you have to care about the peo­ple you work with. You have to find (or build) the right team, engage with them, as peo­ple, as a per­son, and let their strengths shine though. Sev­eral of the founders at Pol­l­enizer visit India reg­u­larly to touch base and keep every­one together and I can’t see how it could work otherwise.

It’s never going to be sim­ple. It’s soft­ware. That’s how it is. (Irre­ducible complexity)

P.S. To my dev team in Trivan­drum, you guys rock. :)