i'm a big believer in planning out programs and structures, but like most of life, it depends on your goals and the scope/timeframe of your project.
i think this kind of approach makes most sense in terms of the famous idea to "plan to throw one away [because you will anyway]".
the idea being that you can't really anticipate and plan everything, so you are better off just plunging right in and expecting that you will learn a lot in the process, and write the *real* permanent code later and throw the initial code away.
if this is your approach, i think it makes a lot of sense to just jump right in, as a learning excercise.
OR
if it's a small enough project and you are a good enough coder (or have written this kind of program before) you may get away with a one-shot fast coding project.
learning what will work and learning how to anticipate issues, and learning what kinds of program and data structures will work for a task is really most of the difference between someone who has been programming fro 15 years vs. someone who has been programming for 2 years. as you get better you will be able to see and anticipate things that new programmers won't.
For bigger projects though, i'd always recommend some planning, especially if you're not prepared to throw one away.. Otherwise it's far to easy to paint yourself into a corner and realize that the foundation of your code is fragile and not well suited to the task.
This issue is also particularly important when other people are going to be using your software. It's far too easy to realize half way in that you are going to have to make some changes to the data files, etc., that will render the new version incompatible with the old. people usually don't like to hear that.
