Right mix of planning and programming on a new project

Question

I am about to start a new project (a game, but thats unimportant). The basic idea is in my head but not all the details.

I don't want to start programming without planning, but I am seriously fighting my urge to just do it. I want some planning before to prevent refactoring the whole app just because a new feature I could think of requires it. On the other hand, I don't want to plan multiple months (spare time) and start that because I have some fear that I will lose my motivation in this time.

What I am looking for is a way of combining both without one dominating the other. Should I realize the project in the way of scrum? Should I creating user stories and then realize them? Should I work feature driven? (I have some experience in scrum and the classic "specification to code" way.)

Update: How about starting with a "click dummy" and implementing the functionality later?

Answer 1

Plan the minimum viable product, and implement that. Then listen to your users and plan the next logical enhancement, and implement that. Repeat.

Answer 2

You're on the right track. There's no need to spend months planning, but you should definitely have some kind of plan.

Planning will help you organize your thoughts, identify technologies you may need, clarify trouble spots, and give you a roadmap to work from that you can break down into measurable goals.

In addition, you may do a few days worth of planning only to discover that this is a waste of your time. Perhaps while planning, you realize that you're way out of your league or that what you're trying to do can't be marketed. It's better to find that out now so you can re-invest your time into other ideas that you have, rather than going down this road only to become lost in the woods, surrounded by stringy code vines and trails of fallible logic that twists your brain into knots.

Answer 3

No matter how much time you spend on planning and designing your program, you always end up rewriting parts of it anyway. It's like gravity, not smart denying its existence.

One must realize that refactoring is a normal part of development and it's just a matter of deciding when you do it. Wait to long and you end up with huge amounts of spaghetti, begging for a complete rewrite. Not funny.

My suggestion is to plan a little but get started coding asap and refactor, refactor, refactor to keep the code in shape. The DRY-principle (dont repeat yourself) is a great indicator for that.

Answer 4

When I'm in this position I sometimes make use of TDD (test driven development) and start planning out some tests for the most complex part of the system I am developing. Alternatively I may put together some high level pseudo code, again for the most complex areas. I find this process gives me a loose plan of action and helps me to identify which areas are likely to be the most time consuming.

For me this approach works because it lives somewhere in between coding and planning. Once you have your test ideas and/or pseudo code you can work through each logical section and implement the code. I often tackle the hardest part of a proposed solution first, because typically the hardest part is the core feature of the application and you can always delay any bells and whistles.

Since you comment that most of the code is in your head and you are ready to dive in and program, using this approach may help you focus on each section without your mind becoming clouded by the system as a whole.

To summarise more succinctly, one could say "tackle the hardest part first, divide and conquer, with pseudo code and/or TDD plans"!

Answer 5

Just try to make the code modular. Anything else you plan is likely to be thrown out during the next iteration.

Answer 6

I would recommend writing your ideas down at the very least. Depending on the size of the project a lot of formal planning might not be required. If however it's very large at all you might want to save yourself a headache and spend a couple of days doing some more in-depth planning.