As this kata is not supposed to be a coding exercise I started out just modeling ideas in my head about how I would do it before I realised that this wasn’t working as an effective way for me to learn. I decided to try and test drive some of my ideas to see whether they would actually work or not. It also gave me the chance to play around with git - I put the code I wrote on github - and re-commence my battle with buildr.

Having decided to fire up IntelliJ and try out some of my ideas in code I realised that test driving straight away wasn’t going to work well - I hadn’t spent enough time designing the objects that I wanted to test. I still wanted to try out my ideas in code though so I spent about ten minutes roughly coding out how I expected it to work before using a test driven approach to drive out the (admittedly simple) algorithms. While Test Driven Development is a very effective technique for driving out object interactions and ensuring code correctness, it was good to have a reminder that there still needs to be some up front design work before diving in.

One of the mistakes I made early on was over engineering my solution - I saw an opportunity to put one of my favourite patterns, the double dispatch pattern into the code. I did this straight away before stepping back and realising that it wasn’t really needed in this instance. Speaking to a couple of my colleagues about this the next day they reiterated the need to keep it simple.

I consider myself to be reasonably competent when it comes to object modeling - it is certainly something I enjoy doing - so I found it a bit disheartening that I struggled quite a bit to come up with solutions to this problem. I decided to return to the book and re-read the chapter. It had this to say:

One unusual thing for me while I was trying out this exercise was that I wasn’t pairing with someone else. I think this made it more difficult as I didn’t have anyone to bounce ideas off and sub optimal solutions weren’t getting rejected as quickly due to the I had a longer feedback cycle. On the other hand, it provided good practice for improving my ability to spot unworkable ideas more quickly.

I really wanted to write the bits of code I wrote in a completely object oriented way. This meant having no getters on any of the classes which forced me to think much more about the responsibility of each object. Although I wrote very little code in this instance, this is a practice that will be useful for me when coding in other situations. I had a bit of difficulty trying to keep the code well encapsulated while also allowing it to describe the domain concepts but hopefully this is something that will become easier the more I practice.