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

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).


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

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

Closing discussion

Try it yourself!

It’s really easy to try this kata out.  Just point your browser at 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.

Other starting points



Filed under dojo, refactoring, teams

6 responses to “Notes from a Refactoring Cyberdojo

  1. gt

    Here is an idea: back in high school, my philosophy teacher taught me that one of the main attributes of Art was to build things that had no functional purpose. A car would never qualify as Art for example, because its main purpose is to drive you from A to B. Or have fun, depending on its use (no, my Touran definitely does not qualify).
    Much later, I started hearing about this “Agile” thing in software development. One of the principles being “Customer satisfaction by rapid delivery of useful software”. I really liked this concept, because it underlined software as a science and not as art. A point that some software developers seem to have forgotten.
    Bottom line: these Cyberdojos seem very cool, but what about making them useful? Get some code out of it and have it be submitted to some (open source?) project, for the greater good? Recycle all these electrons and neurons you have been abundently (ab)using?

    • meekrosoft

      Hi Guillaume!
      For sure, the agile movement has underlined delivery as the only measurement of progress. I agree that this is a healthy direction.

      The main purpose of a coding dojo is to practice, without the constraint of finishing. It might seem strange, but this is actually a very important constraint. When the pressure of finishing is taken away, you are free to think slowly – and this is the state of mind best for learning and discovery.

      I think what you are thinking about is a hackathon, which is also a fun group coding exercise, but has the purpose of developing or improving a given software codebase.

      I think there is room for both :-)

  2. Good job Mike! Nice to see so many people involved, I wish I had the same kinda motivation around me

    • meekrosoft

      Hi Tahar!
      “If you build it, they will come.” Don’t be discouraged, you only need two people to make a dojo happen, and I’m pretty sure you work with at least one person who’d be interested :-) Get the company to pay for lunch and book a meeting room, the rest is easy.
      Good luck!

  3. Hi Mike, thanks for sharing the refactoring dojo link. I will use it in Extreme Engineering this month for a dojo practice.

    Also I would thank you personally for the teaching in the automation workshop at September in Houston. You and James Grenning totally changed me on the way of programming within automation test framework. I enjoy programming with TDD.

    Thank you! I am hoping to read more thoughtful posts from you blogger :-)

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s