Shipping On Time

Cross-posted on my company blog, SouthwestGecko.com.

@IndieGamerChick tweeted a while back “… NEVER set a date for a self-published game”.  This struck a chord with me - on one sense it makes a lot of sense.  Why publish an unfinished product?  Why push to meet deadlines, when the only one who’ll even notice is you?

On the other hand, we’re engineers.  A wise man once told me (OK, my father, but close enough), that the job of a manager is to tell the engineer when the project is done enough.  Remember the definition of an engineer: “One who ‘measures with a micrometer’, marks it with chalk, and cuts with an axe”.  In my 14 years of engineering, I’ve found a lot of truth there, and the problem lies in the measures with a micrometer part of that statement.  Left up to their own devices, engineers (myself included) will typically get stuck in the design cycle, constantly adding one more feature, and never finishing.  Stated another way: “If it ain’t broke - fix it ‘till it is”.

So how do we, as obsessive, design happy, feature happy, develop happy engineers actually ship something?  At this point, I’m going to need to ask you to set down any drinks you may be holding and prepare yourself.  Ready?  OK - the answer is:

Process.

OK - if you didn’t follow my recommendation, you can stop to clean the chocolate milk off your display that just spewed forth from your nostrils.  Process is the answer to actually shipping something.  And yes, I’m still talking about indie developers here.

Process has gotten a bad rap over the years.  Most people hear process, and they think PROCESS.  They think of government organizations.  They’re picturing Big Blue from the 1982 Apple commercial.  They’re thinking of TPS reports.  But those are all examples of process being taken beyond what it’s good at, and being used for its own sake.  The TPS report has to have a new coversheet.  Why?  Because the process says so.

I spent a lot of time working at a big company before I started my own gig.  I’ve seen process handled well.  I’ve seen process handled poorly.  I’ve found over the years that the key to making process work for you is flexibility: on your part, and in the process.

So how do we, as indie developers, who don’t want to be enslaved to PROCESS, use process to actually help us get done what needs getting done?  To start with, stop thinking of it as PROCESS, and take it down a notch.  Breath into a paper bag if you must, but calm down and think objectively.  Process is simply a set of tools and guidelines that help you get what needs doing done.  Think of it as a set of reminders to what you need to do in order to accomplish what you want to do.

Let’s apply a process to shipping an indie game.  Every time I ship software I have a process that I follow.  It’s a very flexible process, but it’s a process none the less.  Until now it wasn’t even documented (don’t tell CMMI!).

Pick a Ship Date

To start with, pick a ship date, and try to make it reasonable, but you can change it later if you want to.  Let’s say I want V1.0 of String Theory Duo to be released 6 months from now.  From there, I work backwards with several key milestones.  The big milestones are:

Ship to Apple for review is self explanatory, but be sure and leave time for several iterations just in case Apple has issues. Go on the long side for new/questionable releases, and the short side for minor updates.

All known bugs patched is the trigger to release your first RC (release candidate) build. For a new game, leave two months for this process (to allow time for final play testing); for updates leave two weeks to give you time to thoroughly regression test. 

The last is the big one: Feature Lockdown.  This is the trigger to start Beta testing.  Why feature lockdown?  because at this point the clock on the process is ticking.  Starting at this point, if you want to add a new feature at this time you can, but you now know that adding that new feature will effectively reset your clock.  You’re in a day for day slip on your release, months in the future, due to adding that new feature.  I find this really helps me to put the unnecessary new features on hold and focus on what needs doing, which is shipping a product.  Leave 4 months for this process for a new build, 1 month or less for an update.

So to add all those up, we’ve got 1 month for approval, 2 months for RC testing, and 4 months for Beta testing.  Which means with our 6 month to release date we were hoping for, we should have had all our features implemented in code a month ago.  Well, now we know…  and that can be powerful.

Identify Features List

Your next step should be to identify your Feature List.  This is the list that you will lockdown against, and I find simply thinking about that list puts a lot in perspective.  You can then start reconciling your rough schedule against that list, pushing features and dates until they line up.

Ship It!

Your new process in a nutshell is:

You now have a very simple, flexible, and powerful process to work with to let you plan out your release process.  Remember not to take the process too seriously, and if you need or want to slip your dates, you can.  You can even figure out how much that slip will cost you and plan for that.

You now have something to work with, and from, and a reasonable expectation of an actual release date.  In the battle of features vs. release date, you’ve just won the battle.  Stick to your new process as best you can, and you too can actually ship software.

Eric