Dojo for Developers

Today I have attended a Twitter seminar related to the Brazil World Cup, applied cutting edge machine learning techniques (with education facilitated by Stanford University) and facilitated a Dojo. Life in WDS development is good. Although the other subjects are of interest, the benefits of performing the Dojo (and feedback received) seemed worth sharing with the world.

Firstly, you may be wondering what a Dojo in programming terms actually is. In Japanese the term is used to mean “place of the way” and is used in relation to martial arts. It’s a respected place where people come together to improve their skills, pass on knowledge to others and have fun. We therefore create an environment for the same to take place, only this time looking at some code and development practices

As well as the above intended benefits, I also organised a DOJO with these (more specific) aims in mind:

• To discuss and highlight the merits of Test Driven Development
  
• Highlight the advantages and pitfalls of common refactoring techniques
  
• Help ensure that future code quality is improved (therefore reducing development costs) by increasing the likelihood of it being written more effectively first time round
  
• Demonstrate the three minutes from safety principle
  
• Least importantly, improve some code (selected due to being a good example to work on for the above aims)
  

In our first DOJO for a year, I thought I would keep the format simple and focus on some code which required refactoring. Firstly I explained the event and code in question. Once everyone was happy we set aside some time for discussing higher level refactoring goals for this code (so we were all heading in a consistent direction). We then had lots of time (1.5 hours) for developing changes. We also kept some time at the end to conclude and wrap up the points which had been discussed before briefly ‘retrospecting’ the event

Upon discussion we found that we had met all of the objectives above. The code was improved to a lesser extent than I had hoping but this was acceptable due to much positive discussion around techniques taking up time that could have been used writing code. The positivity was highlighted by the event being mentioned as a positive thing by many people in the teams retrospective the following day.

Aside from the expected benefits above, other feedback discussion points which may not be obvious to new Dojo-ers included:
WWW (What went well)

• Mood remained positive as there was collective ownership of code
  
• Courage to accept criticism of code helped the session
  

WWW (What didn’t go well)

• Was 15 people too many to be effective in terms of writing code
  
• The cost (especially in terms of man days) should be a consideration for longer future events
  

LL (Lessons learned (apart from the obvious lessons to be taken from the above))

• We felt that Kata style practicing would aid people practicing what was discussed
  
• As would reading material related to refactoring legacy code
  

I hope this has been useful. I am happy to discuss this further and receive feedback in the comments below or on social media

Chris Watkins