Archive for the ‘thoughtworks-anthology’ tag
We ran another Coding Dojo on Wednesday night as part of ThoughtWorks Geek Night where we continued working on the Bowling Game problem from last week, keeping the Object Calisthenics approach broadly in mind but not sticking to it as strictly.
This time we followed the Randori approach, with a projector beaming the code onto the wall, 2 people pairing on the problem and everyone else watching.
We rotated one of the pair every 7 minutes using the Minutes OS X widget to keep track of time. There were 6 of us and everyone had around 6 or 7 times at the keyboard.
The pair switching involved switching the current driver out, the current navigator taking over as the driver, and one of the people from the audience coming in as the new navigator.
What We Learnt
- There were a couple of problems which became apparent early on. One problem we noticed which Danilo also pointed out in his paper was that keyboard shortcuts are a bit of a problem, both in terms of us developing on a Mac and using IntelliJ. My UK keyboard layout also provided an area of difficulty – we’ll probably try and use one with an Australia layout next time.
- We started off using the Hamcrest library for doing assertions but eventually resorted to using JUnit assert methods as these were better known by the group.
- We didn’t stick strictly to the navigator/driver roles when pairing – as we were able to adopt a TDD approach most pairs used the ping pong pairing approach to keep both people engaged.
- After 2 or 3 goes each we noticed that people were always working with the same pairs when they were at the keyboard – we started to mix it up so that everyone got a chance to pair with the others. I think this helped to make it a bit more interesting and allowed us to achieve the goal of working with as many of the group as possible.
- We had the Object Calisthenics rules written up on the board which worked much better for keeping them in mind. We didn’t keep strictly to them but one idea suggested was that if we violated them three times that could serve as a signal to refactor to the rules.
- The problem was a bit too big to allow us to complete it although we managed to get much further than last time. We are going to look for some smaller problems for the next Dojo.
- It was really hard to come into the code afresh at times and try to be productive straight away. I think some of this was down to not being fully engaged when in the audience. Certainly the pair just before your go you need to be completely aware of what is going on. It was also pointed out that it is much easier to come into a pair if we are getting the green bar all the time – it makes it much safer.
- We had 2 or 3 pairing sessions in the middle where there was only discussion and no coding – luckily we managed to turn this around after this wake up call and managed to make quicker progress after this. Calls from the audience to code and stop designing helped drive this.
- The necessity of taking small steps was again obvious. Often we adopted the approach of trying to implement the solution from a very high level test instead of drilling down into smaller tests and then making these pass. Eventually the small steps approach won through and by the end we were chalking off much smaller tests with greater frequency.
For Next Time
- When rotating pairs bring the new person in as the driver with the person who stayed on from the previous pair taking a navigating role to start with to guide the direction of the code.
- Keep a list of the next tasks/tests to write on the whiteboard next to the code. Anyone in the audience can add to this list. The idea is to try and keep the audience engaged while not distracting the focus of the current pair.
- A bit more up front design and discussion of the problem before diving into the code. We still had the situation where we thought we understood the problem but struggled to implement it until we drew it up on the whiteboard about half way through.
- Get the audience to follow the current pair more closely. We often had the situation where the audience was discussing one part of the problem while the pair at the keyboard was coding another part. Trying to get the two parties more aligned is a challenge for next time.
- Get the pair to be more vocal about exactly what they are trying to do. The need to articulate ideas is even greater when there are others in the room trying to follow your train of thought so putting extra effort into this when at the keyboard may work better.
- Try a smaller problem next time – probably one from the Online Judge website.
We ran an Object Calisthenics variation of Coding Dojo on Wednesday night as part of ThoughtWorks Geek Night in Sydney.
Object Calisthenics is an idea suggest by Jeff Bay in The ThoughtWorks Anthology , and lists 9 rules to writing better Object Oriented code. For those who haven’t seen the book, the 9 rules are:
- Use only one level of indentation per method
- Don’t use the else keyword
- Wrap all primitives and strings
- Use only one dot per line
- Don’t abbreviate
- Keep all entities small
- Don’t use any classes with more than two instance variables
- Use first-class collections
- Don’t use any getters/setters/properties
We decided to try and solve the Bowling Game Problem while applying these rules. We coded in Java as this was a language everyone in the room was comfortable with. It would have been cool to try out Ruby or another language but I’m not sure if this type of setting is the best place to learn a new language from scratch.
I hadn’t arranged a projector so we couldn’t adopt the Randori approach. Instead we split into three pairs rotating every half an hour, discussing how each pair was approaching the problem at each change.
Learning from the problem
I was surprised how difficult the problem was to solve using the Object Calisthenics rules. There were several occasions when it would have been really ease to expose some state by introducing a getter but we had to try another way to attack the problem.
We have been following the approach of wrapping all primitives and strings on my current project as ‘micro types‘ so this rule wasn’t new to me but the general feeling early on was that it was quite annoying to have to do. From my experience on my project it does help to encourage a more object oriented approach of keeping the data with the behaviour.
This approach to object orientation is very extreme but the author suggests giving it a try on some small projects as being able to code like this will result in you seeing problems in a different way. I noticed today that I was always on the lookout for ways to ensure that we didn’t expose any state so it’s had a slight influence on my approach already.
We had an interesting discussion about mid way through about whether we should implement equals and hashcode methods on objects just so that we can test their equality. My general feeling is that this is fine although it has been pointed out to me that doing this is actually adding production code just for a test and should be avoided unless we need to put the object into a HashMap or HashSet when the equals/hashcode methods are actually needed. The only alternative I can think of is to not test object equality and instead only test equality where we have primitives or to test for equality by using reflection.
From seeing the approaches others had taken I realised that the approach we took on my machine was too difficult – we would have been more successful by adopting baby steps.
Learning about the format
We initially started out trying to design a solution to the problem on a white board before getting to the coding but this didn’t work particularly well so we abandoned this and went straight to the code.
Each machine had three different pairs working on the problem over the duration of the night, with one person always staying on the machine and the others rotating. While we all had slightly different approaches to the problem it would have been interesting to see if we could have progressed further using the Randori approach with everyone having input to the same code base.
None of the pairs managed to complete the problem, and there was concern that the problem was too big to fit into the 90 minutes we spent coding. After speaking with Danilo and reading his Coding Dojo paper it seems that this is not necessarily a bad thing and the focus is supposed to be more on the learning than problem completion.
It was certainly an interesting experience and I had the opportunity to work with some people that I haven’t worked with before. We are hopefully going to make these Coding Dojos a regular feature and try out some different approaches to see which works best for us.
On this occasion I selected the problem but in the future we would look to make it a group based decision depending on what people are keen to learn.