We took the approach of trying to get a useable front end for the game working as quickly as possible this time which was a bit different to our normal approach where we tend to focus more heavily on the modeling side of the problem. We therefore decided to do the simplest thing that could possibly work and hardcoded the representation of the board as a string, which surprisingly (to me at least) proved adequate for the whole time we were coding and it was only towards the end that we felt we needed to put in a more robust data structure. Certainly a lesson for me of the value of not over engineering a solution.

This led to a discussion around what sort of situation this would represent on a real project. The closest we came up with was that of using an in memory repository early on until a real database is actually needed. We need to trade off the complexity we are adding in by doing this integration versus the gains we get from integrating early.

An cool approach which Nick showed us was to always implement code inline, make the test pass and then extract it into methods or classes as part of a refactoring step. This is similar to the idea of sprouting inner classes which Pat Kua wrote about a couple of months ago. This takes the idea of taking small steps even further which can only be a good thing.

It was interesting to see that without a domain expert we ending up changing the ubiquitous language in the code quite frequently but never really came up with one that made sense to everyone - when talking about the code we ended up with people doing translation between their understanding of various concepts.

The plan for next week is to continue working on Isola - it turned out to be quite an interesting game to try and model, simple enough that we could understand the rules quickly but complicated enough that it takes a while to implement.