Sometimes I stare blankly into space or sketch ideas and write some pseudo codes on paper. Then I scratch it out and start again, then when I think I have the correct solution for the problem I begin writing the code.

Is it normal to think for days without writing any code? Is this a sign that I am approaching the problem entirely wrong? It makes me nervous to not getting any tangible code written in my IDE.

  • 9
    It highly depends on the problem and your individual thought process. If you meet your deadlines, it doesn't matter how much time you spent thinking and how much coding.
    – yannis
    Commented Nov 10, 2011 at 13:13
  • 4
    Did you try drawing out your components on a whiteboard? Sometimes when I am faced with a design dilemma or complex algorithm I just start drawing. If you are stuck then maybe you are trying to digest too much in your mind. Try breaking things down to small and easily digestable components, then draw how these different pieces interact. No need for formal standards, I sort of do a Poor Man's UML when I am on the whiteboard.
    – maple_shaft
    Commented Nov 10, 2011 at 13:18
  • 2
    rather think abt the design for days than implement a bad design quickly
    – Chani
    Commented Nov 10, 2011 at 16:46
  • 4
    Yes it is! And sometimes I look at code I have already written and I wish I had thought more about design before writing it :-)
    – Giorgio
    Commented Nov 10, 2011 at 17:58
  • 2
    Computer Science, ironically, is often independent of computers
    – Ryan Kinal
    Commented Nov 10, 2011 at 19:57

15 Answers 15


Depending on the problem you are trying to solve, the design phase can take weeks and months (if not years), not just days.

It takes experience to not start bashing out code immediately. Thinking about the architecture and high level design should take days if not longer - definitely something that should happen before you start writing your code.

  • 1
    +1 for years. Was involved with a group where in the next room there was a team that'd been involved in requirements gathering for a new system for 5 years, with no end in sight. We seriously doubted whether they'd ever get any further.
    – jwenting
    Commented Nov 10, 2011 at 14:15
  • 8
    @jwenting... that isn't good either, those guys maybe should have started typing. Commented Nov 10, 2011 at 17:07
  • 8
    @jwenting, yeah, that's called the waterfall method, and every one of them should be fired. If you can't figure out what you're trying to do in a year, then you'll never be able to bring it to market before the technology itself becomes obsolete.
    – riwalk
    Commented Nov 10, 2011 at 17:25
  • 1
    I dread what would have happened if they'd started churning out code, they were all business analysts with no technical know how whatsoever :)
    – jwenting
    Commented Nov 11, 2011 at 6:43

This is commonly referred to as "Analysis Paralysis"

It's common but wrong. At some point you need to test out the various ideas to see what will work best for you, then incrementally improve on it.

Recommended reading the Pragmatic programmer Specifically Chapter 2 the section on "Tracer Bullets"

  • 12
    you're wrong in assuming it's necessarily wrong to spend time designing your system. For something trivial, days may sound like a long time, for large systems that will span tens of thousands or hundreds of thousands of lines of code it's far too short a time to even get the basic architecture on paper.
    – jwenting
    Commented Nov 10, 2011 at 14:16
  • 3
    The time spent thinking is directly relational to the complexity of the issue. But if he is "nervous to not getting any tangible code written in my IDE i will" I think its safe to assume he needs to get started.
    – Morons
    Commented Nov 10, 2011 at 14:23
  • 7
    I DID NOT IN ANY WAY SAY its "wrong to spend time designing your system"
    – Morons
    Commented Nov 10, 2011 at 14:24
  • 5
    @Morons: it doesn't matter what you say, what matters is what people hear, and people heard you say that what the OP is doing is wrong. Commented Nov 10, 2011 at 16:30
  • 6
    The term "analysis paralysis" implies that an excess of time is being spent in analyzing a decision. It is indeed a real problem, but it is not at all clear from the original post if that is the case in the present situation. If you are spending a few days to think over how to write a function to reverse a string, that is analysis paralysis. If you're spending a few days thinking over how to write a new c++ compiler before you start, that is the least you could do. Commented Nov 10, 2011 at 16:48

This is completely common. However if you take a "Test first" or TDD approach, it is less common and might help you formulate your ideas better.


Habits are usually a result of trial and error approaches to things and continuing what gives us the desired results and avoiding what doesn't. Doing what we like and avoiding what we dislike comes into play as well. That works up to a point because eventually, we'll do something we don't like in order to get the rent paid.

It depends what lead you to this and your reasons. Here are a few:

  • Too often, you've had to change code because of design changes
  • You don't change a poor design because the lesser solution was already coded
  • You would rather draw and design than write code-procrastination
  • having to worry about the syntax and details of coding, distracts you from thinking about better designs.

Hopefully, you've discovered that if you design longer, your code is better. If you can look back and see that it doesn't matter how long you spend on design, you may want to change. Another consideration is how often you are discovering problems after you've written code compared to working with your designs. If you are not finding issues until after you write some code, you should consider a balance and get to coding something sooner rather than later. Maybe this approach could be applied to the use of newer technologies or a very complex feature.

I don't know if I have the discipline to stick with one approach or the other even when I discover one works better than the other. Sometimes I feel a need to go to the white board; others the keyboard.


It's very common and i feel it's a better way to handle and understand things. While working on a project, I get stuck many a times and it take a day or two to understand as to how can i approach it better. Even after the problem is solved, i wait for a day to pass. This makes me more refreshed and get going.

It's a natural phenomenon and good for a developer to intercept his mind time and between.


When I took a course in project management, one of the things the instructor related to us about planning, that stuck in my head, was that the rule of thumb that they taught in the military was to figure 1/3 of the time for planning. So if you had an operation that required you to be complete 3 months from now, figure on spending one month on planning before you start execution.


In my view, there are three approaches, each suited for a specific coding situation

  1. I've seen a similar problem before so I have a pretty good idea of the patterns to apply, and its clear how the solution should behave and respond.

    => Use BDD/TDD starting from the desired solutions and working in to the code. (Ok, sometimes I cheat and write the a bit of code and then the test - kind of a nested 2. -> 1. approach).

  2. I have a good idea of patterns to apply, but I'm not sure what the solution should look like.

    => Prototype to see what kinds of interesting things pop out. Move to 1. when I figure out which interesting things are desired.

  3. I'm not sure what patterns to apply.

    => Think about it the problem and how the various ways of approaching the problem influence the code. Move to 2) or 1) depending on the outcome of that exercise.

In other words, the answer is the engineer's favorite: It depends.


Better to spend a month thinking and designing than to whip up a quick prototype based on a substandard design that you then have to beat into shape. Especially if you're on a team; once others start depending on your code it's much harder to implement a better design with a different API.


I agree with the other answers that, in principle, taking time to think through a problem/solution is a good idea. However, if you feel like you're stuck, I have a few recommendations for ways to get the planning process a bit more coherent:

  • Create design artifacts. So what if you don't write code? Maybe you just write down a journal of your thoughts. Or a sketch of a general solution. Or even just a really good summary of the problem that you refine over time. As you consider ideas and accept/reject them, keep a log of your reasoning on the subject. This way, at the end of the day you can still point to real-world deliverables as evidence of your labor.

  • Talk to people! There's nothing like having a living, breathing human being with whom to discuss ideas. If you think you're stuck, talk it through with someone. Grab someone--anyone!--and explain the problem to them. Sketch out your thoughts on how to solve the problem. Even if all they do is inhale, exhale, and blink for ten minutes while you babble, chances are you'll discover new insight just in the process of explaining the problem.


As Satchel Paige said, "Sometimes I sits and thinks, and sometimes I just sits."

I guess what he was getting at is that it's sometimes good to clear your mind since it may lead you to think about your problem in a different way. So, if you're not banging away at code you may come up with a solution or idea that might have evaded you otherwise. So, yes, it's normal and a good practice to not jump right into coding.

There are two ways I do this process myself. I create a folder where I have a text file and any drawings related to the project. I jot down my ideas there and try and save the entire thought process as best I can. I'll also create a scratchpad project where I can quickly test out simple ideas from algorithms to CSS layouts.


Program = Algorithm + Data Structure

IMHO, the design(problem solving) process totally rules. Implementation(technical issue) details follow and solve naturally.

  • I really like that simplified equation. +1 Commented Nov 17, 2011 at 6:51

Here's my thought case.

  1. Starting from scratch First a rough idea of what you want is required. Try to get a list of some requirements, or create them. It should take a bit of time to figure things out here. Once you have at least a piece that you are confident you want, knowing most of the interface of that piece, then start coding.

  2. Fixing a problem with existing code First of all, track through the problem. This might require some time of not writing real code (Some debug code might be written, but this typically won't be kept). Once you find the problem, depending on the complexity, start writing code to try and fix it. Little thought should be required once the bug is known. If the issue works out to be a major design flaw, see the next section.

  3. Design changes/ major features This is most likely the one which will require the most thought. Thought as to preserving structure, backwards compatibility, etc. must be included. Thinking through for the best change could save a significant time, but typically for me is not more than a few days.

  4. Adding a simple feature If no significant design change is required, then simply code in your feature, using some trial/error. This shouldn't require a ton of time in general.


I'm going to disagree with the consensus on this one. I'd rather start prototyping something as soon as I have even the vaguest written-on-a-napkin idea of how I want my system to work. It's nearly impossible for me to think of all of the little details that might cause problems unless I'm specifying things in a very precise way. If I'm just discussing design with people, it's too easy to just hand-wave around some of the more complex problems. Once I'm specifying things like this, it may as well be directly in source code rather than some other means of expression that's just as precise and formal but can't be compiled and executed.

  • 3
    There's a difference between figuring out the details and figuring out the basics. For example, if you were to design a language, you would want to decide whether your language was procedural or functional before you got anywhere close to a keyboard. No one says you have to figure out details when planning, but you need to know where you're going.
    – riwalk
    Commented Nov 10, 2011 at 17:28
  • @Stargazer712: I completely agree. That's why I said you need at least a napkin idea what the heck you're going to do. However, the way this question was asked I was picturing days or weeks of formal, bureaucratic meetings before even trying to bang out a prototype of even the most risky/novel/interesting features.
    – dsimcha
    Commented Nov 10, 2011 at 22:53

It depends on what do you mean for "normal". Speaking about myself, I think code is a great learning tool. So, when facing a complex problem, I do sketches on paper but I also do some Test-driven coding. Code tells me thinks that a whiteboard can't say and vice-versa, and maybe the result is insight or the need to a couple more questions to the domain expert.

So the real advice is: "Use every learning tool needed to get closer to the problem definition", but also "remember that these are learning tools, so don't fall in love with them" both code and sketches are meant to be throwaway.


In this era of RAD and agile programming, you should start developing as soon as you can identify major parts of the system, details will come along. Since Softwares are getting bigger, focusing prematurely on every single detail will lead you nowhere.

  • 2
    And not focusing on enough details may lead you somewhere that nowhere is a far better place to be.
    – Dunk
    Commented Nov 10, 2011 at 19:07
  • @Dunk I used three words: Prematurely, every, single about focusing on details. I didn't said to pound the keyboard right away, Get the drift man. Commented Nov 10, 2011 at 19:36

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