Code Dojo II – New Rules

We finally had our second code dojo here at yD. In short, it was another great success! I’m going to split this up into two posts, first off discussing the new rules we implemented, and second discussing the results of the evening.

For those unfamiliar with the term, a code dojo is a chance for programmers to get together and practice coding techniques. The techniques we’ve focused on have been, Test Driven Development, Pair Programming, and Baby Steps. Read more at http://www.codingdojo.org/

After our first dojo we identified some areas where we could improve the experience. So we came up with new rules with that goal in mind:

Moderator
I acted as a moderator and did not participate in the coding. I was responsible for explaining the rules of the dojo, and introducing the problem. I also enforced the rules in a fairly strict manner. Since I came up with the problem, I could be the ultimate arbiter of any questions regarding the problem (generally stuff I hadn’t thought of). Everyone seemed to agree that having someone to direct the flow, and keep the rules in check was a good idea, and worked pretty well.

Silence
Our first dojo allowed questions under red bar, and suggestions under green. We determined that there tended to be too much noise, and on the whole was pretty distracting. So, we went the other way this time and allowed almost no talking at all. We did allow a simple “I don’t understand that” once under green bar. I also tried to keep the pair at the keyboard talking a lot.

Silence seemed to fit well with having a moderator. Participants were able to give comments by calling me over and whispering. These tended to be pointing out any rule breaking that I was missing. Because the pair at the keyboard talked more and the audience couldn’t help but listen; everyone in the room seemed to be on the same page in terms of the code. I don’t remember any audience member not understanding where the code was going. The silent dojo was a bit calmer overall.

Extreme OO
We tried a few of the coding rules from Object Calisthenics. These were One Dot Per Line, One Level of Indentation, and Wrap All Primitives and Strings. Of these it was really the third one that gave the most interesting results. In the end it was a really good idea. The inability to return primitives was heading towards a fairly interesting and fun design. There was perhaps a bit of an issue at the start with ‘class explosion’. Not surprisingly having a rule like this can cause a lot of classes to be created early on. Though not a bad thing, it can be a bit hard to follow for people early on. However, as the night went on it settled down quite a bit, and we were all pretty comfortable with what a Row, Column, Position, Orientation, Length and others did.

Java Specific Problem
In our first dojo, we seemed to get tripped up dealing with input and output. The problem was not exact with how the output was specified and we ended up spending some time in the land of Java Writers and Readers. I hoped to correct this by expressing the problem in more concrete Java. I provided interfaces that represented the input (a String) and the output (some void methods that were to be called under certain conditions).

I don’t know if this helped much or not. The group didn’t have any trouble this time with input or output. But, they also didn’t use the interfaces provided (they didn’t get that far). I would say this was a wash, as it didn’t hurt but didn’t add much value.

No Defined Rota
Since we’re currently hosting these dojos internally, we want everyone who attends to participate in the coding. Our first dojo we decided to do a set order in which people would be coming up to the keyboard. This time we allowed people to jump in when they wanted. I made the point at the start though that we still wanted everyone to participate, and I kept track on the board of who had gone to try to ensure some level of fairness. In the end it wasn’t an issue as everyone seemed good about going at an appropriate time and we managed to get everyone through at least twice.

Intermission
Since we were trying quite a few new things, I also had an intermission at about half way into the coding. The thought was to give everyone a chance to blow off some steam since we were all forced to be quiet. I thought there might be a bit of a domain discussion at that point as well. Everyone really liked taking five minutes to discuss how things were going but it was mainly focused on the dojo itself, there was very little domain discussion. This was not a problem at all. I think we all agreed a short intermission was a good idea.

On the whole, the reaction to the changes was very positive. I felt like the night was another success. In my next post I’ll discuss more details about the problem we tackled, and where we’re going for the next dojo. Stay tuned….

Leave a Reply

Your email address will not be published. Required fields are marked *