''Of course ProgrammingIsThinkingToo.  How can you design unless you think?  TheSourceCodeIsTheDesign.''

Oh? Then why do so many people ask ExtremeProgrammer''''''s 
"where is the room for thinking in Listen/Code/Refactor".
Too many people see analysis or design 
(the noble art of drawing circles and connecting them with lines: BertrandMeyer)
as thinking and programming as menial labor.
Therefore, the following rebuttal
----
Not quite a haiku, but in the same spirit:

	Think before your program,
	 they say, or troubles will find you.	
	But programming 
	 is thinking too.

Prototypes, for instance, are thought experiments.
Done well, small prototypes can serve as precise
analysis models. 
After all, programming languages are the *most* formal
construct imaginable; 
The dumbest things on earth, computers, understand them.
So your programs must be precise to talk to computers, but
if the programs also use good abstractions, they will
talk to people too.

You can always prototype, no matter how complex the reality.
A prototype for an atomic bomb is
	class A''''''tomicBomb {
		enum State { Exploded, I''''''nItsShinyShell };
		final State init;
		Bomb() {
		init = I''''''nItsShinyShell;
		}
		State next() { 
		if I''''''nItsShinyShell detonate(); return Exploded;
		if Exploded throw Exception;
		}
	}
From this prototype, we know that (1) bombs are initially
unexploded (2) when detonated they explode (3) there is
no way to make them unexplode. 
This is abstract, precise, and nobody gets killed.

Write a few classes, if you like, run them.
Try a few variations, shift responsibilities around.
You might be suprised how many issues surface when you
try to do this.
You don't even always have to type it all out; doodle
a few interfaces, and the programmer in you will take over.
One trick that avoids cruft and implementation bias
is programming with Types, Sets (Collections), 
Function Objects, Composition, instead of Assignment and Loops.

Over time, make this a habit in all your programming; think
of all programs as specifications, i.e., what they do,
not necessarily how they do it. It can help isolate you from
overcommitment to implementation details, and reveal 
alternative implementations. Sometimes
the how becomes important. Then think about the what of
the how, and proceed. 

Combine this with refactoring, testing, and occasional
reflection. This makes for happy programming.

-- AamodSane