If you plan on shipping code on some device, whether is it a PC, phone, tablet, game console, whatever – your first priority is to get some code running on that device. Any code. Even it is just a sample project, learn the steps to getting code running on your target device.

I’m going to use the word ‘device’ and ‘platform’ interchangeably here. I am referring to the thing that end users will use to run your app or game.

When I was in school I constantly saw my classmates leaving the ‘porting to device’ task to the very last minute. The common result would be: here is our project running on our PC (launched from an IDE…) because we couldn’t get it working on the device in time. In class, somehow that wasn’t a fail. In industry, that is precisely a fail. I’m still unsure why the professors didn’t insist that students get code running on device as their very first step.

It may come as a surprise to some that similar things have happened in the AAA industry. Most development of console games occurs on PCs, running a PC port of the game engine (although usually not polished enough to ship a PC SKU, but enough to do testing and development on). Time goes by, and the engineers get a version running on the target console. Then more time and development goes by, without testing on the target hardware. This leads to massive crunch near the project deadline to feverishly revise assets and code until there is something that fits in memory, fits on disc, and runs at an acceptable level of performance on the only platform that matters: your target platform.

This simple idea may seem obvious to some, but it still happens. iOS apps developed fully in the simulator, only to discover hidden ‘surprises’ on the target device. Unity games developed in the in-editor player, only to discover major issues the target device. Flash components developed entirely in the Flash editor, only to completely not show up when embedded in their target website.

The studios that do things right, constantly test on device. They set up a fully automated system to build and deploy to the target device, so it is very, very easy to do. It should be easy so everyone: artists, designers, audio engineers, programmers, etc, can see how their work will look and function to the end user.

Running on device is arguably one of your highest risks – if you fail at it, you don’t have a product. People can’t use it. So in accordance to basic project management methodologies, you need to tackle your highest risk items first. If you are late in the development cycle and finally deploy to your target and run into some cryptic crash, is it your code? Or something else? If you deployed earlier you would know whether it was your code or not. It gives you a reference point to look back upon, so ‘it worked yesterday/last week, therefore something since then broke the build’.

Furthermore, while you may have lists of specifications and guidelines, actually getting your code running on device can reveal unexpected limitations or nuances. Even using your product, on device, will reveal lots of things you may not have been aware of or considered. Maybe a button is too small to touch easily when you actually use it on your iPhone – but was no problem when you were clicking with your mouse in the iOS simulator. The problems are compounded if you have platform-specific assets and/or codepaths – if certain things happen ONLY when you run on your target platform, then you cannot claim they work as intended without testing them on said target platform.

Sometimes the process of deployment and running on your target platform just takes too long for iteration, and can’t be sped up any more. I’m not against iterating in some PC editor, or PC build of your product. But if you are deploying elsewhere, you need to test there very regularly.

This was originally posted at www.karlschmidt.net/deploy-to-platform-first-and-often/.