Coding Is Like Cooking

I’m planning to start a new dojo this autumn, called JDojo@Gbg. I was inspired by the guys at Responsive in Linköping, who I met at XP2009. They have been running a dojo for some time now, and find it is an excellent way to introduce programmers from their clients to the ideas of Test Driven Development. I think we could do with more test infected programmers about the place in Göteborg, too.

I already run a dojo as part of GothPy, and Got.rb also runs regular Kata/dojo evenings, but because those programming languages are not mainstream, many developers wouldn’t consider coming along. That is why the new dojo is explicitly going to use Java, or at least, the JVM platform.

I’m thinking about what Katas we are going to tackle at the new dojo, and last night I had a go at KataFizzBuzz in Java. It is an extremely simple problem to solve, and initially I thought it was too easy to be a Kata actually. Then at agile2008 I was looking around for a Kata that Michael Feathers and I could perform in 4 minutes for the “Programming with the Stars” competition, and it seemed to fit the bill. I was quite pleased we got done in that short amount of time (in python of course 🙂

A couple of people have commented that this Kata is actually quite good for teaching TDD, just because it is so simple to solve. People are forced to think about TDD instead of the problem. It can easily be made more interesting by adding new requirements too. So I think I might try it out at JDojo@Gbg.

I just wrote a report about europython on my company blog.

I’m looking forward to Europython in Birmingham at the end of June. Geoff and I are going to be rather busy at it. They’ve just published the programme, and between us we are holding 5 sessions. I’m running a “coder’s dojo“, a “clean code challenge”, and Geoff and I are doing a tutorial on texttest together. Geoff is also giving talks about texttest and pyUseCase.

The coder’s dojo session is a copy of the original XP2005 workshop by Laurent Bossavit and Emmanual Gaillot, only in python with different Katas. The structure is the same though – introduction, prepared Kata, randori, retrospective. I thought it worked really well in 2005, so why change a winning format?

The clean code challenge is an idea I came up with. I’ve written on this blog before about KataArgs, and my dodgy python translation of Bob Martin’s code. I’m interested to know what the python community will make of it. I’m basically planning to throw this code out to anyone who turns up, and ask them to refactor it into better python. I’m of course hoping they will produce some innovative, beautifully pythonic solutions, and show me what clean code looks like in python.

The tutorial on texttest is essentially similar to the one Geoff and I did at Europython in 2005. It’s longer though, a half day, and builds on all the experience we have had since, doing tutorials at XP2006 and agile2008 for example.

All in all, I hope we’ll have some time and energy left to go to the other items in the programme. It looks like being a busy conference.

As I wrote in a previous post, I am organising a workshop at XP2009 called “Test Driven Development: Performing Art”. I am very pleased to announce that I have four pairs of expert programmers willing to perform prepared Katas at it! You can read about it here. I am especially pleased that all the performers are experienced coders with previous involvement in coding dojos in places such as Stockholm, Linköping, London, São Paulo and Helsinki. I think we’re going to have a great afternoon on 27th May.

I am really interested to find out more about this concept of “clean code”, and in particular how it relates to programming language. To this end, I’m still chewing on KataArgs.

My latest idea is to start from Bob Martin’s Java implementation, and translate this as directly as possible into python. My idea is to then refactor it to be more pythonic, and see if it turns out looking anything like his Ruby implementation.

I have put up some code on launchpad, which is my attempt at a direct translation of the Java. It was really interesting to do, actually. Of course I had read the Java before, and followed along in the book all the steps to create it, but actually translating it made me understand the code on another level. When I tackled this Kata from scratch, I also got a much better understanding of it, but this was different.

One thing that jumped out at me was the error handling. It’s much more comprehensive than anything I’ve produced in my own solutions, and also compared with his Ruby solution. So I think it’s a bit misleading of him to say “I recently rewrote this in Ruby and it was 1/7 the size”. Of course it is smaller. It does less. Although to be fair, in a way it does more too…

One thing I found awkward to translate was the use of the enum for the list of error codes. Python doesn’t have a direct equivalent, being dynamic as it is. The other awkwardness was the Java iterator. In python iterators are built into the language, but don’t let you backtrack, or get the current index, unlike Java ones. I was surprised to find how extensively the tests rely on this functionality. To my mind, they probe the internals of the args parser too much.

By far my most interesting observation, though, is the one I want to explore more. This code is well written Java, but directly translated, it makes pretty poor python. Why is that? What, specifically, are the smells, and what are the antidote refactorings?

I will no doubt post more on what I find, (with the help of my friends at GothPy, of course)