Agile Philly

Committed to helping members build better software

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

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.

Views: 72


You need to be a member of Agile Philly to add comments!

Join Agile Philly

Comment by Sebastian Hermida on May 28, 2010 at 8:47am
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!


At AgilePhilly, we have been Promoting Agile Ideas since 1776

AgilePhilly is a not-for-profit user group of volunteers in the Philadelphia area dedicated to better software development practices.


Meetings are monthly. Get meeting reminders by joining here.  

  • Our events are Free but you must RSVP.  We have Evening Meetings in the Western Suburbs, usually on the Third Tuesday.  They usually begin at 6:30 pm.  A sample agenda would be:
    • 6:30-7:00 pm: Eat & Greet & Network
    • 7:00-8:20 Main Topic/Speaker
    • 8:20-8:30 Q & A , Pack-Up, More Networking

  • Our Sponsors cover the cost of pizza / sandwiches for an evening.

Our attempt with the group is to provide an environment where you can exchange ideas and meet with individuals involved in agile community.

© 2024   Created by Ravindar Gujral.   Powered by

Badges  |  Report an Issue  |  Terms of Service