02-dojo.tex

\section{Coding Dojo}\label{sec:dojo}

A \emph{Coding Dojo} is a periodic meeting (usually weekly) organized
around a programming challenge where people are encouraged to
participate and share their coding skills with the audience while
solving the problem. The main principles of the \emph{Coding Dojo} are
to create a \textbf{Safe Environment} which is collaborative,
inclusive, and non-competitive where people can be
\textbf{Continuously Learning}. Some of the XP principles align nicely
with that~\cite{XP2E}, such as \textbf{Failure} -- it is OK to fail
when learning something new -- \textbf{Redundancy} -- one can always
gain new insights when tackling the same problem with different
strategies -- and \textbf{Baby Steps} -- each step towards the
solution should be small enough so that everybody can comprehend and
replicate it later.

There are some general rules that allow the \emph{Coding Dojo} session
to be productive and to flow.  The meeting is held in a room with
enough space for all the participants and usually requires only a
projector and a computer or laptop. Having whiteboard space for
sketching and design discussions is also valuable. The participants
are encouraged to develop the solution using Test-Driven Development
(TDD)~\cite{TDD} and are free to choose whichever programming language
they prefer. There are two main meeting formats:

\begin{itemize}
\item \textbf{Prepared Kata}: In this format, someone has already
  solved the proposed \emph{Kata} prior to the meeting (alone or in
  group) and the solution is presented to the audience during the
  session.  Instead of showing the final code and tests, the
  presenters start from scratch, explaining each step and allowing the
  other participants to ask questions or make suggestions. The session
  goal is that everyone should be able to reproduce the steps and
  solve the same problem after the meeting.
	
\item \textbf{Randori}: In this format, the participants solve the
  problem together, following TDD and Pair Programming in time-boxed
  rounds (usually between 5 and 7 minutes). At the end of each turn,
  the pilot joins the audience, the co-pilot becomes pilot, and a new
  co-pilot joins the pair from the audience. An extra rule is that
  discussions and suggestions should only be given when the pair
  arrives in a green bar, with all the current tests passing. The
  reason is that, while on a red bar, the pair should focus and work
  together to pass the tests. The audience can always suggest
  refactorings and optimizations on a green bar.
\end{itemize}

\begin{figure}[htp]
\centering
\includegraphics[width=\columnwidth]{dojo}
\caption{A typical Dojo Randori session}\label{fig:dojo}
\end{figure}

These formats allow the creation of an environment where participants
can discuss and practice a wide range of topics, such as: TDD,
Behaviour-Driven Development, Agile, Refactoring, Pair Programming,
Object-Oriented Design, Algorithms, different programming languages,
paradigms, and frameworks.

\subsection{Coding Dojo@SP: History and Process}\label{subsec:dojosp}

The meetings of the São Paulo \emph{Coding Dojo} started on the $12^{th}$
of July, 2007 and have been held weekly since then in the Institute of
Mathematics and Statistics of the University of São Paulo. Some extra
sessions were done during the University holidays and most of the
session reports are available on the international \emph{Coding Dojo}
wiki\cite{DojoWiki}. The number of participants varied from 3 to 16
and their skill level ranged from undergraduate students to
experienced programmers.

At the first meeting the participants were asked to fill index cards
with their expectations and personal interests in attending the
sessions. An affinity map was built with that information and the
three main interests were to practice problem solving skills, to learn
different ways and algorithms to solve the challenges, and to learn
new programming languages. Some of the sessions were highly focused on
design problems and algorithms, which left less time for writing code,
but the participants liked to learn from the discussions. On the other
hand, the majority of the sessions required less design and algorithms
discussion, leaving more time to write code and allowing the
participants to experiment with a wide range of programming languages,
such as Java, C, Ruby, Python, Lua, and Smalltalk. The sessions usually
follow the same process:

\begin{itemize}
\item \textbf{Problem Choosing} (5 to 10 minutes): Before the meeting, the participants
  receive an e-mail with 3 to 5 options of problems to be solved. The
  problems are chosen from several sources (such as Ruby
  Quiz\footnote{\url{http://www.rubyquiz.com/}}, Programming
  Challenges\footnote{\url{http://www.programming-challenges.com/}},
  UVa\footnote{\url{http://acm.uva.es/p/}}, and
  SPOJ\footnote{\url{http://www.spoj.pl/}}). Each option is briefly
  presented and the participants vote on which problem will be solved.
  %This usually takes 5 to 10 minutes.
	
\item \textbf{Problem Discussion} (10 to 20 minutes): Once the problem is chosen, the
  group discusses the different approaches to solving it, usually
  ending up with an agreed approach and a list of TO-DO items, as
  proposed by Kent Beck~\cite{TDD}, to guide the pairs during the
  implementation. %This usually takes 10 to 20 minutes, but there were
  %meetings when the group spent the entire meeting discussing
  %algorithms and possible approaches to a complex problem.
	
\item \textbf{Coding Session} (1 to 2 hours): With an agreed approach to solve the
  problem, the participants start the coding session in one of the two
  formats -- a \emph{Prepared Kata} or a \emph{Randori}. They should
  practice Pair Programming and Test-Driven Development as a general
  rule. %This usually takes 1 to 2 hours.

\item \textbf{Retrospective} (10 to 20 minutes): At the end of the
  session, the participants stop coding (even if the problem was not
  completely solved) to reflect on the experience and share the
  learned lessons with the group. %This is also a good time to discuss
  %what could be improved and to come up with action items for the next
  %meeting.
\end{itemize}

Finally, the São Paulo \emph{Coding Dojo} came up with two special
roles that can be rotated between participants, but that are very
important to organize and to make sure the meetings continue to
happen. The \textbf{Moderator} or \textbf{Organizer} is responsible
for what happens before, during, and after the meeting. He handles
tasks such as reserving the meeting room, sending reminders and
options of problems to be solved, setting up the computer and
projector prior to the meeting, moderating discussions, conducting the
retrospective, and cleaning up the room after the session. The
\textbf{Scribe} is responsible for publishing the results of the
session and sharing it with the people that could not attend the
meeting. He handles tasks such as posting the session report to the
wiki, publishing the final source code to the group, sometimes taking
photos, and documenting the results of the retrospective.