Minesweeper Dojo

This evening I facilitated our first coding dojo at work. I’d spent some time over the holidays putting together a progression of Cucumber acceptance test cases to build up the solution, and had solved the problem once myself.

I used the minesweeper kata from http://codingdojo.org/ which was a really nice easy problem for our first dojo I think.

Format

Executive summary:

• Randoori format
• 6 programmers (plus me, facilitating)
• 2 hours.
• 10 minute iterations
• 10 minute retrospective at the end.

I was clear at the start to point out that it was rude and disruptive for the crowd to criticise design when tests were failing, but that once tests were green, we would have a design review and do some re-factoring.

In fact, as we got into it, we began stopping the clock for design discussions (though perhaps these could also be timeboxed to keep the urgency up) so that people got a fair chance at the keyboard, but we also got plenty of time to analyse the design.

Summary

I held a little retrospective at the end where we collected some thoughts, then a few of us went for a pint afterwards and talked about it some more.

Good points:

• Most people seemed to enjoy working on a ‘toy problem’:
  • everyone had worked on it equally so design discussions were never personal
  • we could really focus on getting the best solution to the problem, because it was so simple
• Doing it out of hours meant we could really relax and have fun with it
• It was a great way to get the team to rapidly build consensus about conventions and coding style
• Having flog stats in the rake task made the final re-factoring stage much more worthwhile and fun

Bad points:

• Some people found the problem too easy to solve, meaning we spent a fair amount of the session ‘polishing’ a working solution
• I forgot to reset the stopwatch sometimes, which meant things got stale
• There was a tendency for people to just rotate in / out in order which meant you kept getting the same combinations of pairs In the end I started drawing them out of a hat
• We suck at git, particularly moving files from one branch to another
• We suck at understanding flog’s feedback very well

Ideas for next time:

• Find a way to visualise the changing Flog scores between commits
• Try other programming languages
• Need to mix up the type of kata: some people would prefer doing things they’d find more challenging, like a tough re-factoring
• Get some food and beer in
• Try shorter iterations?
  • In fact, try short / long pairs and see which we prefer!

I tend to perfectionism, so I really enjoyed the last half hour where we just re-factored the right-but-ugly first solution to the problem, extracting methods and classes and moving code around, ironing out the wrinkles and getting the flog / reek scores down. I enjoyed the discussions as we traded off different design principles and weighed up the appropriate route to take. Some people definitely found this time less rewarding, but I wonder whether they rather missed the point: this isn’t about solving a tough problem – we do that all day – this is about solving a simple problem the right way so that next time we hit one of those tough problems, we might be able to solve it a little more elegantly.

Legacy

I put the git repository where we worked on the problem up on gihub here:

http://github.com/mattwynne/software-craftsmanship-katas/tree/master/minesweeper

I would be stoked if anyone forked the repo and pushed their own solution. How low can you get your flog scores?