Mark Needham

Thoughts on Software Development

Coding Dojo #2: Bowling Game & Object Calisthenics Continued

with 3 comments

We ran another Coding Dojo on Wednesday night as part of ThoughtWorks Geek Night where we continued working on the Bowling Game problem from last week, keeping the Object Calisthenics approach broadly in mind but not sticking to it as strictly.

The Format

This time we followed the Randori approach, with a projector beaming the code onto the wall, 2 people pairing on the problem and everyone else watching.

We rotated one of the pair every 7 minutes using the Minutes OS X widget to keep track of time. There were 6 of us and everyone had around 6 or 7 times at the keyboard.

The pair switching involved switching the current driver out, the current navigator taking over as the driver, and one of the people from the audience coming in as the new navigator.

What We Learnt

  • There were a couple of problems which became apparent early on. One problem we noticed which Danilo also pointed out in his paper was that keyboard shortcuts are a bit of a problem, both in terms of us developing on a Mac and using IntelliJ. My UK keyboard layout also provided an area of difficulty – we’ll probably try and use one with an Australia layout next time.
  • We started off using the Hamcrest library for doing assertions but eventually resorted to using JUnit assert methods as these were better known by the group.
  • We didn’t stick strictly to the navigator/driver roles when pairing – as we were able to adopt a TDD approach most pairs used the ping pong pairing approach to keep both people engaged.
  • After 2 or 3 goes each we noticed that people were always working with the same pairs when they were at the keyboard – we started to mix it up so that everyone got a chance to pair with the others. I think this helped to make it a bit more interesting and allowed us to achieve the goal of working with as many of the group as possible.
  • We had the Object Calisthenics rules written up on the board which worked much better for keeping them in mind. We didn’t keep strictly to them but one idea suggested was that if we violated them three times that could serve as a signal to refactor to the rules.
  • The problem was a bit too big to allow us to complete it although we managed to get much further than last time. We are going to look for some smaller problems for the next Dojo.
  • It was really hard to come into the code afresh at times and try to be productive straight away. I think some of this was down to not being fully engaged when in the audience. Certainly the pair just before your go you need to be completely aware of what is going on. It was also pointed out that it is much easier to come into a pair if we are getting the green bar all the time – it makes it much safer.
  • We had 2 or 3 pairing sessions in the middle where there was only discussion and no coding – luckily we managed to turn this around after this wake up call and managed to make quicker progress after this. Calls from the audience to code and stop designing helped drive this.
  • The necessity of taking small steps was again obvious. Often we adopted the approach of trying to implement the solution from a very high level test instead of drilling down into smaller tests and then making these pass. Eventually the small steps approach won through and by the end we were chalking off much smaller tests with greater frequency.

For Next Time

  • When rotating pairs bring the new person in as the driver with the person who stayed on from the previous pair taking a navigating role to start with to guide the direction of the code.
  • Keep a list of the next tasks/tests to write on the whiteboard next to the code. Anyone in the audience can add to this list. The idea is to try and keep the audience engaged while not distracting the focus of the current pair.
  • A bit more up front design and discussion of the problem before diving into the code. We still had the situation where we thought we understood the problem but struggled to implement it until we drew it up on the whiteboard about half way through.
  • Get the audience to follow the current pair more closely. We often had the situation where the audience was discussing one part of the problem while the pair at the keyboard was coding another part. Trying to get the two parties more aligned is a challenge for next time.
  • Get the pair to be more vocal about exactly what they are trying to do. The need to articulate ideas is even greater when there are others in the room trying to follow your train of thought so putting extra effort into this when at the keyboard may work better.
  • Try a smaller problem next time – probably one from the Online Judge website.
Be Sociable, Share!

Written by Mark Needham

November 13th, 2008 at 10:39 pm

  • I was also thinking that it might be interesting to start with a solution that needs refactoring. For instance, start with the solution that the Bob’s came up with, and spend the time refactoring it.

    Perhaps it’s not the same exercise that you are going for, but I think it would be interesting. The downside to this is that they made certain assumption about the interface that I think new development could do differently (and changing during refactoring would be borderline rewriting the solution). For instance, the assumption that you feed the object a single number at a time – there are other ways to model the input.


    Interested in combining with the SyXPAC coding dojo?

  • Pingback: Coding Dojo #3: Krypton Factor at Mark Needham()