In my previous post I discussed the basics of what a Coding Dojo is and why you’d want to have one.
I host a Coding Dojo at my work every month, so I’ve decided to periodically update an index page of example Katas. They are usually based off existing Katas which are available on the main Coding Dojo website. I’d also recommend the prolific Sao Paulo Coding Dojo.
You should be able to reuse the same problems at your own Dojo. If you have any other recommendations then please email/twitter me, or comment on this post.
On a slightly related note, I just completed the common Minesweeper Kata.
Matt Wynne, who has an excellent blog, recently created a test harness using the Ruby BDD framework called Cucumber. It acts as a great way to introduce you to BDD and Github if you haven’t used them before.
A Coding Dojo is a programming session based around a simple coding challenge. Programmers of different skill levels are invited to engage in deliberate practice as equals. The goal is to learn, teach and improve with fellow software developers in a non-competitive setting.
I’ve been running a Coding Dojo at JPMorgan in Glasgow for over a year and I’ve found it to be a fantastic way of encouraging people to stretch their coding muscles and meet other fellow developers who they haven’t met before.
Background
Researchers at Florida State University have been trying to find out what makes certain people experts in a craft. They have studied people recognised as world class in their fields like Tiger Woods, Warren Buffet and Luciano Pavarotti to find out whether they are excelling as a consequence of possessing innate gifts or due to hard work.
Their research found that elite performers in many diverse domains have been found to practice on average the same amount every day, including weekends, over a period of at least 10 years. There is an intrinsic link between deliberate practice and high levels of skill.
The renowned pianist Vladimir Horowitz supposedly said, “If I don’t practice for a day, I know it. If I don’t practice for two days, my wife knows it. If I don’t practice for three days, the world knows it.”
Dave Thomas seized upon this idea in his book The Pragmatic Programmer. He suggested that programmers should be practising small problems outside of their job regularly, repeating the same problem in order to learn from previous mistakes. To encourage people to practice he posted a series of Code Katas on his website. The word Kata comes from martial arts and is a practice of repeating a small movement repeatedly in order to perfect it.
One of the limitations with the Code Kata is that when you complete the task on your own, you don’t receive any feedback. An important positive stimulus found in research around deliberate practice shows that having a master in the craft available to you while you learn is crucial.
Laurent Bossavit, a determined Parisian, decided that practising Katas at home was keeping this beneficial element away from him. He created the Coding Dojo concept, where he would present a rehearsed Kata from scratch in front of an audience. His weekly Paris Dojo started in 2005 and it has since inspired many other programmers to start their own.
Principles and Rules
The premise of a Coding Dojo is to promote continuous learning in a safe environment. It is both non-competitive and inclusive. People of different skill levels collaborate together, encouraging each other to talk openly about design and techniques.
The rules used at a Dojo depend on which format the Dojo uses; one rule that must be adhered is that you elect to use either Test Driven Development or Behaviour Driven Development. These practices allow for greater testing of a codebase and allow developers to express their needs from that codebase.
Everyone participating should be able to go home and recreate a solution to the same problem. If one person doesn’t understand, then the coding should stop until they are confident with what is taking place.
Formats
All Dojos take place in a room with at least one laptop over two hours. There is an overhead projector available where people can display and speak about their code. The Dojo itself can have differing formats which control the different way developers interact.
Prepared Kata (Parisian)
The Parisian style of Dojo requires the most effort up front by an individual. A single developer starts from scratch and codes a Kata in front of an audience. The developer will have tried the problem a few times before and shows their solution to the crowd over the projector.
While the presenter creates their code they are constantly speaking to the audience letting them know exactly what they are doing and why. Any member of the audience is allowed to interrupt the presenter and ask them why they are coding in a certain pattern.
Randori (Finnish)
The Randori style of Dojo was created by the Agile Finland group as a way of making a more interactive Dojo. It involves developers programming in rotating pairs to design a solution to a problem. The problem and proposed programming language are voted on before the event by the participants.
No one is required to have done any research into the problem before the Dojo begins. Pairs are given a 7 minute time frame to code in front of the audience; once their 7 minutes are up, another person from the audience replaces a member of the pair and takes over.
This format requires dedicated concentration from the participants in order to be successful. Because of this a person is normally made product owner to make sure that everyone is paying attention to the progress the current pair are making.
Individual Pairs (Glaswegian)
Due to the upfront effort required of the prepared Kata and the dedication needed for a Randori to succeed, I’ve been using a different approach at JPMorgan. The format I use is to introduce a problem, then split the group into pairs who choose their own programming language to craft a solution in. After two hours of coding the pairs perform a short presentation on their codebase, showing the progress and design they’ve made.
Start a Coding Dojo at Work
Hosting a Coding Dojo is a very cheap and effective way to train and improve with your colleagues. All you need is a room with a projector and some willing developers with laptops. It doesn’t require much money and it’s not complicated to set up. There are a lot of sample problems available online already and participants don’t have to attend every Dojo.
A Coding Dojo represents a different challenge to developers. It encourages them to speak to an audience about their code, which is a different skill to producing it. These skills are developed during a Dojo as it stimulates social and self organisational skills. It makes people become more rounded software engineers and discover potential areas of improvement.
So what’s stopping you?
Attending a Coding Dojo can help you improve enormously; it is a fun and challenging experience you share with other developers. It encourages deliberate practice by working together on a common problem during which you can learn, teach, accept criticism and defend your ideas. You will receive feedback not only on the code you produce, but the techniques you use. You will be exposed to new ways to use your favourite language and some different tricks you can perform with your code editor.
As Ron Jeffries points out “What changes people is what they do, not what they read. How many diet books have I read? Am I thinner?…”
Have you experienced Integration Hell? Do you find that sometimes broken code gets into the mainline without anyone noticing?
These practices can occur frequently. A way to combat this is to adopt the mindset of Continuous Integration (CI).
Background
CI is a development methodology involving daily developer integrations verified by automated builds. Martin Fowler wrote the original article on CI:
“Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily – leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly” martinfowler.com
The Fowler article highlights that adopting CI represents a sizable shift in the process of building software. Integration usually happens infrequently, resulting in a small effort today being replaced with a lot of pain later.
CI changes the developer approach by encouraging frequent integration as part of their daily activities.
Risks of not doing CI
Without CI the team can lack cohesion (incompatible conflicts, different libraries in use, “I thought you fixed that bug 3 months ago!”).
Lack of Visibility: Not knowing when a build fails or your code coverage.
Integrating late means fixing bugs late, which is costly.
Benefits of CI
CI allows you to develop software faster, better and cheaper.
Faster: No integration points. Release builds become a non-event.
Better: Tested early and often. Consolidated metrics though a CI Server.
Cheaper: Identify defects earlier and fix when least costly.
Easily repeatable testing.
Prerequisites to adopting CI
In order to take advantage of CI you will need to already have your source code in a repository such as Subversion or Clearcase. You will also need to have adopted an automated build tool such as make, maven or an equivalent.
The biggest benefit you can get from CI is when you have a suite of automated unit tests. If you don’t have unit tests then you will only have the validation that your code can compile, not that it functions as expected.
CI will not work if you want to use:
Nightly Builds.
Developer Branches.
Scheduled Integration.
Building via an IDE.
If you can match these prerequisites then you will be able to take advantage of a CI with a CI Server.
CI Servers
A CI Server acts as a centralised build machine for your project. It is possible to practice CI without a CI Server but it isn’t advised. CI Servers give you a web interface that allows you to see the status of your project within different environments.
To get started with a CI server you make a job which knows where your codebase lives. You then give it a simple script which can be run from the command line. The CI Server will then continuously poll your source code repository for changes, if it detects a change then it will check out your codebase and run your build tool. It will then report back the result of the build including if anything has broken.
CI Servers offer different mechanisms for reporting feedback on builds. A few common options are email, instant messaging, RSS, IDE integration and tray icons.
This feedback gives developers confidence that their changes are working with everyone else’s and allows them to continue to develop with that reassurance. This is especially important when a developer is performing a large refactoring task.
Rules for CI
In order to get the most out of CI, there are some rules that you need to follow:
CI is a development methodology which takes getting used to, but it allows you to develop software faster, better and cheaper. Teams within organizations are building software in a CI Server as you read this.
While the choice of CI Server differs within organizations, Hudson is getting a lot of support as it is free and has a large community creating extensions.
Software developer, systems thinker, merciless refactorer and agent of change terrorising Glasgow
I run my own business providing software services throughout Scotland. I mainly use Clojure, Ruby, Java and any automation tools I can get my hands on.
I can usually be found hacking on side projects, writing music or enjoying a fine single malt whisky.
