Mark Needham

I attended an open space hosted by Emily Bache at the XP2010 conference in Trondheim, Norway with several other people who have been organising coding dojos around the world.

It was really interesting to hear about some of the different approaches that people have taken and how a lot of the issues we had with the one we used to run in Sydney were the same as what others had experienced.

These were some of the things that I took from the session:

• We talked about the difficulty of keeping up the enthusiasm/energy for a coding dojo over a long period of time and Emily suggested that one way to reduce this problem was to link the dojo with a group which met up for something else other than just a coding dojo.

  For example Emily runs a dojo with the Ruby and Python user groups whereby one week someone would do a presentation on something and the next week they would run a dojo.

  The one we ran was generally internal to ThoughtWorks so we had a different problem in that some people preferred a coding dojo and others preferred to hack on problems alone but with others around.

• Another suggestion around this was that rotating the organiser between the group was a way to keep enthusiasm up and made it the whole groups’ responsibility to keep the dojo running rather than placing the responsibility at the feet of one or two people
• An idea suggested by Mariana & Hugo from their experiences running a dojo in Sao Paulo was how to introduce a new language in the dojo environment.

  They originally tried just running a randori style dojo but found that this didn’t work out so well if there wasn’t at least one person who had enough experience to at least know how to setup the development environment and write some tests in the language.

  The approach they took was to have one person do a prepared kata in the new language at the beginning of the session and then after they’d done that then the rest of the group would participate.

• Another suggestion was to run a retrospective on each dojo session where people would write down what they had learnt from the session and what had hindered their learning.

  This strikes me as something which would be quite useful to consider even on a normal project, especially near the beginning, and would help us to at least recognise if there are factors which are preventing us learning as much as we’d like. We could then do something to fix that if necessary.

• Hugo and Emily both suggested the ‘Kake’ format as one which might be better suited in a dojo with people who are quite experienced with the dojo idea.

  In this format there would be more than one computer being used and pairs would rotate between the stations.

  At each station the same problem could be being solved in a different language or a different problem in the same language.

• I also learnt that we had misunderstood the way we were supposed to pair in a randori dojo.

  We somehow had the idea that the driver was supposed to drive for the whole 7 minutes and the navigator would just navigate during that time and then they would be the driver next time around. Emily pointed out that the idea is just to pair normally but have one person rotate after 7 minutes.

  This makes much more sense to me and would have made our sessions much more natural than they felt at times while we tried to follow this idea.

I gave a presentation at our ThoughtWorks Brazil office in Porto Alegre last way on some of the things that I’ve learned while working at ThoughtWorks and the first point I made was that it was better to ‘ask for forgiveness, not for permission‘.

This was something that was taught to me a few years ago and the idea behind this is that if there’s some idea we want to try out it makes much more sense to start trying it now and then we can always apologise later on if someone has a problem with us doing that.

This is in preference to an approach where we ask whether we can try out an idea and get told no straight away i.e. we should look to be proactive.

It’s really easy to say no to something when you don’t really no what it is you’re being asked and it seems to be the default answer a lot of the time.

An example of something where this rule may apply would be if we wanted to try writing some tests with a different language/framework to see whether it improves the way we’re doing things.

We don’t really know whether the new approach is going to be better than the current one so it makes sense to spend a bit of time playing around with it so that we can find out.

Later on in the talk I suggested that on some decisions it makes sense to gather data and then let the client decide what they want to do.

An example of this happened on a project I worked on a couple of years ago where the value of writing functional/unit tests was being questioned.

My colleague Kristan Vingrys came up with a matrix which showed the risks of not testing various features and then let the client decide whether they wanted to take that risk. Alex wrote more about this at the time.

After I mentioned this Caio pointed out that this idea seemed to contradict the idea of asking for forgiveness and not permission and at the time I couldn’t really think of a good answer to why I didn’t feel the situations were exactly the same.

A week on I think that the difference is that the ‘ask for forgiveness’ approach applies mainly for new situations where we haven’t agreed as a team what we should do and people don’t have enough information yet to know whether we should or should not do what is being proposed.

The idea of gathering data and letting the client decide applies more when a decision has been made or suggested and we want to try and influence that decision.

It doesn’t make sense to just do what we want in this situation if it explicitly goes against what the client wants but equally we don’t want to do something which goes against what we believe is the best approach without at least pointing that out.