What Matters in a Dojo?

We in the Austin Code Dojo have been doing weekly dojos for four weeks now, in Genuine Joe Coffeehouse in North Austin, Texas. We’ve been learning a lot in these sessions.  Here are some of my notes.  These mostly talk about what matters in a dojo.  What are the important things we’re doing and why are we doing things this way?

The order that you come up with the tests really matters.  The tests drive the solution and shape what it will be.  Starting with simple tests (or tests with simple solutions) is crucial, but the order you progress is also important.  There’s a certain art involved here, and I think that’s one of the things we’re learning.

The names of the tests really matter, too.  First, they organize your thoughts when you’re initially writing the tests.  Second, when a test fails, especially one you didn’t expect to fail, the test name should tell exactly what happened.  So, for example, if frobnicatingAnEmptyFoobarShouldThrowAnException fails, you know frobnicate()  isn’t throwing an exception when passed an empty Foobar.

The early phase of a TDD kata is about creating the API.  We tend to spend a lot of time on the API, because it is very important.  For example, at one point we were working with a complex method-driven API, and it was getting complicated, and it felt like we were getting into design.  We switched to a simple string input/output API, and suddenly it was easier to get through those first tests.  Design moved back into the solving-the-test phase.  Those early tests created the API, and we had to get them right to proceed.

The reason we divide tests and solutions is because they are two different domains.  When we are writing the tests, we are working in the problem domain.  What is this program supposed to do?  When we are fixing the tests, we are working in the solution domain.  How is this program going to do it?  Separating the two ensures that you’re not mixing, that you’re not designing in the problem domain, nor defining in the solution domain.

You should envision the eventual architecture of the program, but that’s just a road map.  It’s not where you start, it’s the route you think you’ll take.  And, like a map, once you get out on the road, you might find yourself taking a different approach.

We’re still working on all of this, and learning more and more about TDD and programming in general.  Please, come join us.

Austin Code Dojo
Mondays, 8pm to 10pm
http://groups.google.com/group/austin-code-dojo

Genuine Joe Coffeehouse
2001 W. Anderson Lane
Austin, TX 78757

Tags: code kata, coding dojo, deliberate practice, lessons learned, software development, TDD