We've all read the examples about how valuable planning is, but I'll include my own to prove it. Let's take two developers: Bob and George. They both come from a programming background, and they're both working on a similar style of game. Bob knows the value of planning, and he writes a detailed plan of exactly how is game is going to turn out. George decides to "wing it", and just scrawls a few screens and flowcharts. He'd much rather program, and whilst Bob is still "wasting his time" planning, George has a good head start. Stupid Bob!

Twelve months later, and Bob has finished his game well before his deadline. In fact, and it's a top seller all over the world. He's rather pleased that he "wasted" that time planning.

And what happened to George?

His game never got completed, because he overlooked several problems that Bob found in the planning stage, and it was too hard for him to fix. He doesn't have a proper job now, but for $5 he'll love you long time.

Ok, so I made that entire story up, but it illustrates an important point – planning is good.

So why do we hate it when it's so valuable?

It sounds obvious, but planning is not programming, so there's already some resistance. There's often a one dimensional view of what's involved with completing a game - it won't get completed unless it's programmed, so any activity that isn't programming is seen as a waste of time.

There's often a feel that the plan needs to be absolutely perfect. Here's the good news - it doesn't. Plans can often change during the course of development, and this is perfectly normal (within reason - too many changes are a symptom of "feature creep"). It's more important that the plan is kept updated, rather than remaining stagnant and outdated because nobody dares to change it.

Writing a big plan is scary on two fronts.

First, we've often seen the huge, monolithic design documents that large software companies churn out. You know the ones I'm talking about – they're the kind that weigh more than the entire development team. Indie design documents can be much more lightweight, as they don't need to cover all the corporate red tape.

The second scary thing is confronting exactly what is going to be involved in creating the product. It forces you to look at the big picture, and accept the fact that creating a 3D engine in a weekend is just a pipe dream. It's never easy to admit that you can't do something, but planning and scheduling a project helps you to develop more realistic expectations and will save you a lot of pain in the long run.

What's more exciting? Writing a new whizz-bang particle system, and watching colourful sparks fly across the screen, or writing about it? Exactly.

Perhaps the biggest problem is that planning can be hard work. Thrashing out all the details of a project is difficult, and it makes you realise just how complex software construction is.

Thankfully, it gets easier with practice, but it's still a pain to get a good plan completed.

One hour of planning can save anything up to ten hours of implementation work. I think that's reason enough.