Personal Productivity Stack Exchange is a question and answer site for people wanting to improve their personal productivity. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm not really an organised person, and my maxim is "two weeks of coding will save you two hours of planning". But before every (simple or complex) project, despite how long I'm planning, drawing schemes and thinking about how to do it, always at the end (and/or deadline) I suddenly come up with a solution, that is, in most cases, way easier, more efficient and directly solves the problem.

Is there any technique (which propably is more sophisticated than "just" sitting, thinking about project's flow and analysing the more wicked parts of project), to avoid that?

Or maybe the question is, is this a problem that is not meant to be got rid off, because it's a natural order of self-learning?

share|improve this question
It's called experience :) – Juha Untinen Apr 10 '13 at 10:49

What I used to tell my clients was: 60% to 70% of my time will be spent preparing and/or planning. This is probably most analogous to the Pareto principle of 80% of the value coming from 20% of input. It's what you do during that planning that makes the difference.

If you are "just sitting around" thinking about it, and plotting a course, there's probably not much being gained. Instead, try to view planning almost as if you were a mad-scientist in a lab.

For example, let's say we are building a website or app (you mentioned coding, which is why I went there). Start thinking of ways to layout the user interface - I use rapid paper prototypes - I sketch them out on index cards, using a medium to broad tip marker. Play with it as if it were real. Keep incrementally upping the sophistication - moving to using your favorite graphics applications to layout wireframes - keep playing with it - reformatting as you go. As you start to build a more concrete concept you can begin to see how the code will have to work to give you the results you want.

Break things down into small components - maybe you have a designed something with a lot of progress bars, for example - write something to create progress bars. When you write it the first time it will not be the best/most elegant solution - accept this. In Test Driven Development terms I've seen this referred to as Red, Green, Refactor. There is a problem with no solution. There is a solution. Refactor the solution to make it better (more readable, simpler, etc.). Then you can move on to the next bit. Eventually, all these tiny pieces will come together to form a complete whole that is/should be relatively elegant, because you spent the time "experimenting" with the implementation - not just sitting around thinking about it.

In conclusion, if you can use the fastest and most low-tech methodology to begin testing your hypotheses regarding various pieces of the project, you can quickly gain a more complete understanding of the desired outcome. Basically, allow yourself to go down the wrong paths a little bit and try to put things in place to minimize the possible negative affects of sweeping changes at the end (automated unit tests, for example).

Hope that helps. If you would like clarification on anything, let me know.

share|improve this answer
I wouldn't put more than 30% of time on preparation (yet no less than 10%), because most of the time you don't know what obstacles you'll face unless you do it. That is, unless you're doing something where failure is catastrophic, like banking systems, buildings, or vehicles. Of course, the higher the complexity of the project, the more time spent into planning/communication, but anything more than 50% is extreme for an individual. – Muz Apr 11 '13 at 3:52
@Muz - Agreed. That is why you are not spending 70% of the time "just sitting around thinking about it" - you should be testing your hypotheses as well. However, with a mindset that this is not the final thing. The problem being addressed in the question is things later are better - which is true - but, only after experimentation; however, Pablo seems to be working under this thing I am doing now is the final way. Hope that clarifies "planning" in the context of the answer. – Josh Bruce Apr 11 '13 at 11:42

In any kind of engineering, it is to be expected that inferior solutions result if you skip planning your projects. No matter what project management method you use (Waterfall, Agile etc.) you need planning to avoid choosing a poor route.

Planning a project normally involves evaluating different ideas, technologies, proposed user interfaces etc. Often mockups and proof-of-concept programs are created. The need for research is turned into regular backlog items to be handled. And sometimes the best way will be to consult external experts.

share|improve this answer

My friend, you've come across a principle of life that most people never learn:

  • You need feedback to improve.
  • You don't get any real feedback unless you do it.

Planning has diminishing returns. You won't ever know everything about the project, and very often it takes more time to think of all the things that can go wrong than it would take to get it wrong and fix it.

One of the most powerful planning tools is the checklist. It's easy to do, not as intimidating and 'snobby' as gantt charts and other bulky management tools, yet more powerful. I always say that every meeting should end with a checklist in everyone's hands. Checklists often capture the main points you need to do, yet leave enough room for creative interpretation.

You want to improve your rate of feedback. This often means failing more or not planning as 'tightly'. Prepare for failure. For coding, set up a good system of logging and exceptions. If this is your first time doing something, don't plan to win, plan for feedback.

Work iteratively. As Josh said, Test Driven Development is a good way to continually work on feedback. Break things down into replaceable components. Get your inputs and outputs between components consistent, then keep upgrading those components to be more beautiful and more efficient. Component-based programming is why object oriented programming is so popular.

Prototypes are also vital when venturing into unknown territory.. have something that the final system doesn't rely on, test it until it breaks.

share|improve this answer

Agree with the answers above. Also, this may have an element similar to, when looking for lost objects, "it's always in the last place you look." I mean this in the sense of, of course the last idea you have is going to be the best approach, otherwise you wouldn't remember it.

As for the rest, others have said it already. Keep at it!

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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