Notes from a Refactoring Cyberdojo

We have regular coding dojos in our office. We do a different problem every time, trying to solve it as best we can, using solid design and test driven development. In a typical dojo we work in pairs to solve a well-defined problem incrementally. The main focus is to improve software design and TDD skills through deliberate practice.

Last week we tried something different: instead of solving a problem from scratch we would try a refactoring dojo. A refactoring dojo follows the same format, except instead of starting with a blank page we start with a fully implemented solution with full test coverage.

Why would we work on a problem that already solved the problem and had full test coverage? I mean, if the code works and there are tests, then aren’t we already done? This is an opportunity to practice refactoring skills, but the motivations run deeper than that.

A coding dojo is an opportunity to practice coding, away from the usual constraints of the working environment. One of the main constraints we have in our daily jobs is actually finishing tasks. Many an agile consultant has filled a conference talk jabbering on about Definition of Done, but the reality is that every developer makes a judgement call about when the code is good enough for check-in. So the refactoring dojo is an opportunity to see how far we can go when we don’t have the pressure of finishing the task.

Refactoring Dojo

The starting point was an implementation of Yahtzee calculator created by Jon Jagger for one of his training workshops. It was expertly crafted to contain a large collection of code smells and opportunities for improvement. In other words, it really sucked! :-) (it actually takes a lot of creativity to craft code like this, thanks Jon!).

For the first session we used the cyber-dojo software to solve the problem. In the second session we repeated the exercise, but instead using visual studio and resharper. In both sessions we rotated computers at regular intervals (the countdown timer on the wall shows how much time before next rotation).

Retrospective

We had each table work together to answer three questions: what went well, what wasn’t good, and what surprised you. Each group discussed amongst themselves and when there was some agreement they wrote their thoughts on post it notes and put them on the board when they were ready.

Juven at the whiteboard

Good Things:

Pair rotation, so can learn a lot from others.
Quick communication and diverse opinions.
Baby steps.
Automation tests saved the day.
Cyber-Dojo is cool.
It is fun.
Sample code/problem is interesting.

Bad Things:

Not enough time for each pair session. (10mins instead of 5mins could be better)
The whole Dojo could last longer time.
Cyber-Dojo sever is not stable enough.
VS2008 has refactoring tools while Cyber-Dojo records the history, no perfect tool.
While switching pair, big change w/o enough test coverage was found.

Surprising Things:

Code has so much space to improve.
We can make big changes so quickly.
There are so many different ideas, working style, and tool usage from different people.
Cyber-Dojo is amazing.
While switching pair, someone found people leave code with many tests commented out.

Once everyone had a chance to finish we all ended up around the board discussing the various items.

Closing discussion

Try it yourself!

It’s really easy to try this kata out. Just point your browser at http://cyber-dojo.com/diff/show/E4466E24B2?avatar=elephant&tag=26 and select “Start a new practice kata from here”. Then you will use this version of the kata as the starting point for your dojo.