ProgrammingIsThinkingToo

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

Oh? Then why do so many people ask ExtremeProgrammers "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 AtomicBomb {
		enum State { Exploded, InItsShinyShell };
		final State init;
		Bomb() {
		init = InItsShinyShell;
		}
		State next() { 
		if InItsShinyShell 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