NZ to teach programming in schools

I’m pleased that computer programming is becoming part of the NZ school curriculum.

But lets not forget that the tech industry is a multi-diciplinary one made up of designers, testers, UX specialists, marketers, business folk – not just programmers.

I hope the proposed curriculum is much wider than just ‘teaching programming’. Programming isn’t for everyone, and if kids are (wrongly) led to assume that if they can’t code they can’t be in the tech industry, then that will be a major loss for a generation of kids, and our country.


  1. Don’t labour the fundamentals. Let them discover, don’t make them learn sorting algorithms. Lets not make Python the new Shakespeare.
  2. Focus on creativity. Allow kids to decide what they want to create, them empower them to do it.
  3. Focus on collaboration. Demonstrate how utilizing different talents in a team can allow us to create something amazing.

Ultimately, kids will teach themselves, but we set the paramters. Lets get this right.

Well… we won!

Backstage at the Sports Emmys. Left to right : John Rendall – Animation Research Ltd, Ian Burns – Oracle Team USA, Jimmy Spithill – Oracle Team USA, Stu Sharpe – Cannonball Software, Nathan Martin – Moving Pixel.

Last week in New York, the America’s Cup Official Mobile App won the Emmy award for the category Outstanding New Approaches – Sports Event Coverage.

It was wonderful to be able to share the excitement with friends and family back home through social media and email.  More than one person was telling me to “Get off Twitter and enjoy yourself!”, but in truth I really was enjoying the virtual celebration happening online as much as the party in NYC.

I’m very honoured to have been part of such a talented team. A huge thanks to Ian Taylor and John Rendall of Animation Research Ltd for making this happen. Animation Research Ltd is a company that brings together smaller local companies, giving us access to networks and opportunities that we could never get otherwise. More companies need to start working like this, as this is how we create *true* growth in the New Zealand tech sector.

Here’s the TV One story.  Kudos to TVNZ’s US Correspondent Jack Tame, for getting these shots so soon after the event – we were still buzzing, as you can tell.

Kiwi designers win Sports Emmy for America’s Cup app

Here are some photos from the night and trip home.  Enjoy!

Cannonball is off to the Emmys!

This project really is the gift that keeps on giving.

We woke up on Wednesday morning last week to the amazing news that the America’s Cup app has been nominated for an Emmy award!   Under the category ‘Outstanding New Approaches – Sports Event Coverage’.

If that wasn’t enough of a buzz, I found out that I’ll be attending the ceremony in New York on May 6th.  A HUGE thanks to Ian Taylor and John Rendall of Animation Research Ltd. for generously offering one of the limited invitation spots to me so that Cannonball can be represented at the awards.

Here is the excellent entry video created and submitted by ARL, which earned us the nomination. Enjoy!

America’s Cup App – TV3 story

Brooke Gardiner of TV3 spoke to us as part of a story on the America’s Cup App.

That’s me on the pier on Kelvin Peninsula in Queenstown.  Very lucky to have such a good view from my office.  Fishing isn’t bad either.

Big thanks to all involved, and especially to Ian Taylor and John Rendall of Animation Research Ltd.  This is a great example of a New Zealand company that chooses to work with local talent and can encourage true growth of our local tech sector, by giving smaller developers access to opportunities and networks that we would never be able to get ourselves.

Animation Research Ltd (ARL) contracted in other devs as well as ourselves that didn’t get explicitly mentioned in the story, but deserve a shout-out here:

– Nathan Martin, Moving Pixel, Dunedin.  (Design)

– James Sugrue, SoftwareEx, Timaru (Android port)

– George Sealy, Greengage, Dunedin (3D viewer in Live data mode)

ARL also developed and published the official Emirates Team NZ app.  For whom we also need to thank:

– Michael Tandecki, Six Foot Three Foot, Wellington


Kiwi-made America’s Cup app impresses Apple



This is cool..

Ben and Phil from Virtual Eye, watching the Lous Vuitton Cup action live on the Americas Cup app while covering the PGA Championship in Rochester NY.


(image courtesy of Virtual Eye)


Lets Go!!

Cannonball is moving to Queenstown, New Zealand!

This has been a plan in the making for around two years now, so we’re very excited about the move.  Myself, I’m looking forward to returning to my old stomping grounds and giving my kids the same lifestyle that I was so fortunate to enjoy growing up.

When I settled on my chosen career, I had resigned myself to the fact that I would likely never return to this wonderful corner of the world.  And yet, here we are, 15 years on and lucky enough to work in an industry that allows you to work from pretty much anywhere.

I’ve been glad to have met some more developers, much like us, currently basing themselves in the Queenstown/Wanaka area.  I really hadn’t expected there to be much going on in the area development-wise, but was stoked to find that there is a little scene cooking all on its own.




America’s Cup mobile : Video

Here’s the preview video for the America’s Cup mobile apps.  Cannonball worked with  Animation Research Ltd. to produce the iPhone/iPad versions.  Enjoy.

What makes a great game developer.

At Cannonball, we leverage our background in game development to create new types of user experiences for other domains.  More people are playing games than ever before – particularly on mobile – and as a result we’re seeing more games technology and mechanics being applied in mainstream apps.

This is a talk I did for the Xero Summer of Tech seminar series in 2010, while still working at Sidhe/PikPok.  The first half is a state-of-the-industry overview, the second half is more tech-focused and is aimed at programmers who wish to get into the industry.

EDIT : Having rewatched this video, I noted how much has changed since 2010 when I gave this talk:

  • OnLive is now all but defunct.
  • I stated that C++ is still the preferred language of most game developers.  Given the explosion of mobile and Unity3D, I’m not sure that this statement applies to ‘most’ game developers anymore.
  • 3D Gaming has not turned out to be the next-big thing. At all.

HTML vs Native Code : Why Choose?

Mozilla HTML5 evangelist Chris Heilmann, posted an article dispelling some HTML5 ‘myths’ that devs often cite when rejecting the technology in favour of native code, which on mobile you can read as Objective-C (iOS) or Java (Android).

The post itself made some good points I thought, except when he makes outright misleading statements like this:

“Native applications need to be written for every single device and every new platform from scratch”

.. er what? Anyway, moving along..

I found it through Reddit’s /r/programming, and as with many such discusssions it was dominated by those who felt very strongly one way or the other. You know the stuff : the native-camp decrying the crappy performance or tools, the HTML5 camp citing the standardisation and write-once-run-anyhere type mantras.

All valid points I’m sure.  But heavily polarised discussions like this seem to miss the obvious middle ground.

You Don’t Have to Choose

Its a false dichotomy.

You really can have your cake and eat the hell out of it. I do it all the time. It tastes delicious.

It works like this. All platforms provide ways to embed HTML5 content in your native app. iOS uses UIWebView, Android uses android.webkit.WebView and I’m sure WP7/8 have an equivalent. How much of your content is split between HTML5 and Native is entirely up to you, but I tend to split it along these lines:

  • Native Code : UI elements that need to be responsive or look like familiar OS UI items? Use the native platform APIs. Tables, Navigation bars, etc.
  • HTML5 : Content that needs to be highly customisable, visually identical across all platforms, or needs to change frequently? Use HTML5 embedded in a web view.

The strength of a mix-and-match approach is that it is entirely adjustable during development, you’re not bound to any particular path. Once you see how much flexibility there is in keeping app content online, you may choose to move even more stuff out of native into HTML5. If something is a bit ‘chuggy’, slow to load, or just looks crap in the platform’s web view, you might decide its worth investing the time to do separate native implementations for each of your platforms.

But you know what I like most? At some stage your client points to another app and says “make it like that”! When that time comes you will have options, not limitations, and you can avoid lame sheepish excuses like the following:

  • <arbitrary technology framework> doesn’t support that”,
  • “its kind of supported, but its buggy”,
  • “you’re not thinking the HTML5/Java/iOS way” (please never say stuff like this to a client, just don’t).

Instead, you can give a response, framed with factors your client actually cares about:

  • time,
  • user experience,
  • risk.

Requirements and designs are going to change.  Locking yourself into a particular framework will limit your future options.  So why limit yourself at all?

Don’t Make me Learn

Of course with this approach is that you need to know (or have researched) both HTML5 and as many native technologies as your platforms dicate!  Objective-C/Java/.NET/etc.

Oh the horror!

I’m sure some people would consider this a major drawback.  I don’t.  The more you know, the more options you have, and the better your products will be. You might not get to know everything in depth, but nobody does. Technology choices should be driven by client and product needs, and shouldn’t be constrained by what you already know or are comfortable with.

Just think – you get to learn! And you’ll get better across everything! How cool is that?


So, horses for courses really.  You can easily marry HTML5 with as much or as little native code as you desire.  Both approaches have advantages from which you can cherry-pick the best bits on a feature-by-feature basis.

Or don’t.  By all means, go purely with one or the other if your project requirements justify it, but don’t feel that you have to commit yourself to one path just because thats the way the sideline commentators want to frame the options for us.



Welcome to Cannonball.

Hi all.

You’ve found us.  Come for the coffee, stay for the conversation :).