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?


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.

  • The targeting platform is my daily work, so I do know most of the technologies I want to use. I guess I will use simple scrum and a basic plan. So I can start by some backlogs and do the planing on each iteration. – WarrenFaith Mar 20 '11 at 13:42
  • You keep spelling "planning" wrong. Just thought I'd point that out since I can't edit your comment :) But yes, I think scrum is a great approach has it maintains flexibility and gives you a chance to decide if it's even worth the effort to continue the project. – jmort253 Mar 20 '11 at 20:53
  • O.o In German it is the other way around: planning with one n and programing with two m... :D Thanks! – WarrenFaith Mar 20 '11 at 20:55
  • @WarrenFaith - Sorry! That's my ethnocentrism coming out! Thanks for pointing out my mistake ;) – jmort253 Mar 20 '11 at 21:18

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

  • 3
    .... and every time you have an idea for something that you think would be cool just write down the idea into scrum-backlog but do not implement until the minimum viable product is done. – k3b Mar 20 '11 at 10:12
  • the main question still is how deep I should plan it. If you could give me that advice, too, you got the answer accepted. – WarrenFaith Mar 20 '11 at 13:36
  • 1
    @WarrenFaith: features ->> stories -->> test cases. – Steven A. Lowe Mar 20 '11 at 21:45

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.

  • Thanks for your reply. I know that refactoring is nothing unusual but I don't want to prevent refactoring caused by missed planing. – WarrenFaith Mar 20 '11 at 13:35
  • @Warren - failing to plan doesn't prevent refactoring. You can either code the solution on the computer, or attempt to code it in your head or on paper. I think both of those are ineffective. Start coding, knowing you will change it later. – kevin cline Mar 20 '11 at 15:30
  • @kevin cline: Ok, lets make the difference between refactoring existing code for new feature or improvements and rewrite nearly the whole app for a new feature. I can live with the first, not really with the second.. – WarrenFaith Mar 20 '11 at 15:51
  • @WarrenFaith: As long as the code is tight and in shape, you should be able to avoid rewrites. Only time I've seen rewrites is when the system has become a big ball of mud (no refactoring), or fundamental technical change (change of platform). – Martin Wickman Mar 20 '11 at 18:26

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"!

  • I am not a fan of TDD but thanks anyway! – WarrenFaith Mar 20 '11 at 13:40
  • I'm not necessarily saying use TDD, my point was that it is something I use as a structure to "plan" my code. That way I'm not jumping straight into writing my code and I'm not spending a long time writing mass documents/project plans that are a little too far away from actual coding. It's about finding the happy medium. You can achieve the same thing in principle with a pen and paper. I should also point out that I don't write a test for EVERYTHING - just the more complex areas. – BradB Mar 21 '11 at 22:31

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


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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.