Design is the fun part of writing a program. After you have analyzed what you want, and after you have decided what tools you have that you can apply to the problem, you can sit down and begin to think about all the wonderful classes and functions that you are going to write for your tools to implement your solution. (That is, if your tools support the use of classes and functions.)

(I don't mean to imply the WaterfallModel here; it is certainly possible to "pipeline" everything so that you're beginning the design as the analysis comes out, or to "iterate" so that if you find a problem in your analysis you can go back. But design is cognitively distinct from analysis or coding, even if all three are done by the same person in the same hour.)

Design is practical fantasizing. Once you are finished with design (or a small codeable piece thereof), you have built your castle in the sky; the next stage of the process is to attach it to the ground by coding everything (in that piece). Designing creates the data. CodingIsJustDataEntry.

I don't think it's fair to assign design to some people and coding to others; that's like creating a caste system, since one job is more fun than the other. If you design, it's good discipline for you to ''code'' what you design; that's the only way to know for sure that it is ''possible'' to code what you have designed. -- EdwardKiser

If you are spending significant "non-design" time in coding, that's probably a sign that you should be using program-generating-programs or a more expressive programming language to start with.  The ''computer'' is supposed to do the tedious bits, remember?  -- DanBarlow

Yes. But sometimes TurningTheCrank manually is cheaper than getting the automation set up. -- EdwardKiser