Creating a drawing is a lesson in software creation...

[John Ferguson]

I often struggle with my inability to say code verbally without writing it or drawing it. Sometimes I start out TDD and then my inner well of code overflows into the code and I find from myself or my pair I need to stop! I ask myself why do I do this? Why do I jump into code? I like tests, I love tests more than you can imagine because I hate lots of words for documentation.

I was beating myself up over this while driving to work recently and it dawned on me. How do I draw? My drawing has two phases usually:

• A rough, complete, imprecise explosion on paper - a sketch and ghost of a final form.
• Then if I like the idea I go back and set up the blocking of areas, balance space, add in lines to calculate vanishing point for perspective, measure element proportions (such as limbs), and chose a light source. An important outcome of this activity is that the guardrails in a drawing are removed when done (erased or colored over).
  

So the first event has a parallel in coding - the spike. It is my non-verbal moment when the code overflows out of the silent inner well. No tests, no guide lines, no measure of proportions. Just get something to go end to end. That is my rough sketch for the idea.

The second event is generally marked by the explicit use of guardrails - for our current tools and languages we use Unit Tests with Mocks. We establish the measures from assert and verify checks. In this process though there are some "scaffolding" assertions or verifications that get deleted as we reach the end point.

One key difference from drawing is that the final guardrails (Unit Tests) are checked in with the code. To me these tests are the "meta" to speak to others on behalf of the code.

At this point, the take away I hope to convey here is that a "Sketch" == Spike and that is a holistic view of the end goal. "Properly Composed Drawing" == Test Driven Design Code and is more reductionist. Each test speaks to a facet of the solution. I find I can think a lot about good drawing habits I have read about and learned which can be applied to software. That is to me is a smell, a good smell that software is still an Art.

[Sebastian Hermida]

Hi John,

This past week, I found myself doing a little bit of what you describe there.

The sketching part works great when you are exploring new technologies and you are not sure how the final drawing is going to end up.

So instead of following and delivering incremental stories, we went for broad instead of deep, touching all stories on the surface, and quickly moving through the whole canvas to get an idea if what we want to build with our new tools is doable.

Like testing a new brush and getting the feel for it...

Thanks for your post!