One of the exciting parts of software development is the ability to move as fast as your code can be written. This does not obviate the need for a strong product plan, a solid architecture, a compelling use case, a way to get the word out about your product (if it’s for consumers,) and all the rest of the “stuff” you’ve gotta do.

Got all that stuff? Or some semblence of it? Great. You can code it now.

But how do you know when to stop coding? Do you stop coding when the product is “totally done?” Do you stop coding when the product is “totally perfect?”

Chances are, for business reasons, you’ve already got a version of something out in the wild. (If not, hurry! Release something!) And because of that you’ve got quite the collection of user experience issues and software quality issues you’re working through. Your bug tracker is sagging under the weight of all these open tickets. New wireframes are being thrown together at an uncomfortable rate.

So now you’re faced with the much harder question: when do you release the nextversion?

If your product is web-based, this answer is pretty simple. You can just publish changes as soon as they’re ready. One change at a time if you want. A/B test a few changes a day. Or maybe your deployment systems aren’t quite that nimble, and it’s not responsible to do that. Whatever schedule you decide, your new version becomes available for use immediately.

These days though, you might be talking about a mobile product. Mobile products are downright monolithic. Compared to web applications, your users are practically buying a boxed copy of your app from the store, receiving updates through the mail on 3 floppy disks.

Apple and Google are doing their best with automatic update mechanisms, but you’ve still got to pack and ship a version that you can deal with your users having for well after you release the next one. And in the case of an iOS or Mac app, you’ve got to deal with an approval process that’s going to ensure a botched update is hanging around long after you’ve had your fill.

This “style” of application throws a wrench into even the most nimble iterative development process. At the corporate level, it can be downright paralyzing. How can we be 100% sure this version is THE version? How can we be sure it’s going to be well received and something we want people using for the next month, two months, whatever?

Through a somewhat terrifying mix of pragmatism and optimism, I tend towards the following mental process for determining if something is “good to go” for release to the iTunes Store or Google Play. This is, of course, assuming you’ve reached the end of whatever development cycle you use.

Is there something we absolutely have to release?

Sometimes, for business reasons or technical ones, you’ve just gotta push some code to the store. Maybe Apple’s inisisting you support a new technology, or drop support for an old one. Maybe a new operating system introduced a critical bug into existing code. Maybe you paid for a fleet of skywriters to advertise a new feature and they simply cannot change the date. SHIP IT!

Has it been longer than a couple of months since an update?

Hello? Are you alive, app developer? You never call, you never write. SHIP IT!

Do we have a lot of open bugs that we found since the previous release but haven’t fixed yet?

This one is typically where you start to get crippled. Every piece of software has bugs. The apps we all use every day have bugs. But how often are they encountered? Are they generating user complaints? Are they affecting more than 1% of your userbase? Will the sky fall if these bugs make it into the next release as well? If so, they fall into step 1. Fix them, then immediately SHIP IT! Otherwise, … you know what to do.

Is the version sitting in source control markedly, objectively better than the one sitting on your user’s phones?

If so, without a doubt, you must SHIP IT.

Here’s to ensuring we can all overcome our release paralysis and move a little bit faster releasing the new versions of our mobile applications. Because everybody loves an app update.