SDTConf 2010: First Reflections
TDD Without Frameworks? Really?
Sometimes all it takes is for someone to suggest you do something that you’ve never tried before, and suddenly you’re doing something you didn’t know you could do. That’s what happened today in @chzy’s “Make it Sing” hands-on openspace session at SDTConf today. His suggestion that we TDD sans-framework provoked @joshwalsh and me to create a TDD framework called Really? which we developed by TDD’ing itself. What cracks me up is how easy this was to do.
true.really?
This, of course, will fail with a method missing error. Fix the error, and you’re on your way to
false.really?
You can get the source code for really? at github.
Practice, Practice, Practice
I really enjoyed the strong emphasis on coding practice at this year’s SDTConf. Two of the tracks had overhead projectors, and they were usually being used for looking at, refactoring, or writing code: whether it was the hands-on refactoring little shop of horrors that @auditty unveiled (this session was a blast, btw), or the strange, alien world of J and APL which @kaleidic demonstrated for us, or the Game of Life in Javascript being diagnosed/optimized by @zspencer and @DocOnDev.
The Icebreaker
In addition to sessions where code and coding were being demonstrated, there were also many sessions where everybody opened their laptops to practice coding. The first of these was @kbaribeau’s “Coding Icebreaker.” In that session, we took turns pair programming the bowling score kata. The catch, however, is that sessions were only 10 minutes long. At the end of the session, one person remained at the same workstation, and the other moved down. This means that you get to spend up to 20 minutes with each codebase, and that you get to see 3-4 codebases. There were three implementations in Java, and one in Ruby. I worked with all three Java implementations, but never got in front of the Ruby one.
Each approach was very different, and the “many-cooks-in-the-kitchen” aspect to this exercise made it very challenging to do more than 1) read/grok the code, 2) write a test and 3) make it pass. Some folks commented that leaving the code with a failing test was actually a nice thing to do, since fixing a failing test is often an easier task than writing the next failing test. I’ve always found this to be true.
Tick Tack Toe Driven Development
I also had fun in the “TDD Like You Mean It” session, doing the Tick Tack Toe Kata. I was pair programming with @angelaharms who was fairly new to Ruby although not new to development or TDD. Her newfound enthusiasm for Ruby completely tracks with the way I felt when I first began learning that language, and it was fun walking through the “Like You Mean It” process using Rspec.
We caught some critiques from @chzy and @nashjain because of the fact that we created a Board class. And I could see their point of view. Others argued why not make the Board class if you know you’re going to need it anyway.
I personally am not bothered by the fact that we created a Board class because we were nevertheless focused on small, TDD-invoked steps. We started our rspec file with:
describe Board do
And then, of course, the first thing rspec told us is that constant “Board” wasn’t initialized. Feed the test. Away we went.
I later redid the exercise without creating a Board class. I’ll have to show it to @chzy and see if it’s closer to what he was looking for.
Next year we may be hosting SDTConf on the Leandog boat in Cleveland. That would be hugely fun. We shall see.
Scanning The Topics
I have scanned in the open space topic cards from SDTConf 2010. If you were there, please feel free to tweet/comment/blog/download the card images.
