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.

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.