Last Friday, Keith Braithwaite came to youDevise and ran his “TDD as if you mean it” workshop here in our offices. For those not familiar with how the workshop runs, Gojko has a good writeup of the session as it was run at the Software Craftsmanship 2009 Conference.
The puzzle as presented is one of the basic rules of the game of Go – Atari: A stone (or chain of stones) is in Atari when it has only one liberty.
Our job was to express that in code, but we had some constraints:
- Only have one failing test at a time
- Write implementation code in the test itself
- Only move passing code
- All new methods are written in the test class
But more than the contstraints was the ongoing extreme exercising of YAGNI, and that’s where a lot of the magic of the exercise resides.
As I was the organizer of the event I wasn’t actively participating in the workshop myself. At first I was a bit dissapointed by this, that quickly faded as I realized that it gave me the chance to see all the different ways my co-workers came at the problem. Initally I expected we would all be doing the exercise in Java, but it turned out that three languages (Java, Ruby, and Scala) were out to play. At first a number of the participants jumped ahead into setting up domain objects in an attempt to create the example scenarios, however this was discouraged, and everyone was pushed (both by the constraints, and by Keith himself) to go small and stay small until it was absolutely necessary to do more. It was the repeated exercise of pushing against that pain, and making ourselves stay there that was the real eye-opener. By not putting things into the code until we absolutely needed to, we left our code open to surprising possibilities, like discovering that even the concept of a stone isn’t really needed, by modeling a chain of stones not only do you easily cover both the single and multi-stone scenarios, but you can also remove the need to determine the color of neighbours. My first instinct when I heard the scenario was to model a stone, but even the act of doing that simple modeling pushed me away from the above discovery of the elegance of using the chain.
I felt a lot of push-back internally with the exercise (and I wasn’t even doing most of it!) Going small feels so *slow* sometimes, but all of that questioning can give you incredibly small, elegant, and most importantly, nimble code, and that can save you incredible amounts of time going forward.
Many thanks to Keith for running a very interesting and thought-provoking workshop!