Last Saturday I attended the second Kraków Code Retreat which was a part of the Global Day of Code Retreat. The event was organized by Kraków Software Craftsmanship society, [sckrk].

The organizers did a great job preparing the meeting. There was even a coffee machine for those who, like myself, can’t start a proper coding day without a cup of coffee (or two). Because the event started so early (between 8 and 9 AM), the organizers ensured that we have sandwiches for breakfast. It was a very nice surprise.

On the contrary, the form of the event was not a surprise for me. Partially because I attended the previous code retreat [sckrk] organized in April and partially because the form of these events is pretty much standardized. There are 5-7 sessions, each about 45 minutes long. During each session we try to solve exactly the same problem (the most popular one is Conway’s Game of Life) the best way we can. The assumption is that we work in pairs and we all employ TDD. The amount of time is calculated in such a way that it should be very difficult to finish the solution. The reason for this is, during a code retreat, you should not focus on getting things done but, instead, on writing the most beautiful code you can.

I was quite surprised by the fact that we (I paired with Piotr Leszczyński for this session) managed to solve the problem within the provided time frame. Especially given that I did not manage to solve it during the event in April. The key to our ’success’ (remember, it’s not the completeness of the solution what matters here) was probably the fact that we both have had some experience in both pair programming and TDD. What is more, we did practice these disciplines together in some point in time. I really enjoyed these 40 or so minutes. It would be worth attending the event even for this one session. On the solution side, it was not particularly clever or beautiful. It was not purely object oriented and some abstractions were missing. But my feeling was it was a good SOLID code. The downside of having a complete solution in first try was that I was under it’s influence for the rest of the day. It was hard to think in a completely different way.

The effect was, I spent two sessions refining this solution. One of the improvements was making the coordinates a class on its own. It encapsulated the way neighbourhood (the key concept in Game of Life) is defined. We didn’t have enough time to make the last step and make our game board generic of T where T is an implementation of some Coordinates. It would make changing the coordinate system (for example to spherical or 3D) a trivial task.

The other improvement was made in the method that returned neighbouring coordinates for a given coordinate. In the first solution we just hard-coded it like this:

yield return new Coordinates(x, y - 1);
yield return new Coordinates(x, y + 1);
...
yield return new Coordinates(x + 1, y);

The improved solution looked like this:

return (from x in Enumerable.Range(-1, 3)
from y in Enumerable.Range(-1, 3)
select new Coordinate(x, y))
.Except(this);

It puts grater emphasis on the intent. It would be even better if Enumerable.Range method has min and max parameters instead of min and count.

Like I said before, one of the assumptions of core retreat is to test drive the design. The problem with this approach is, it is hard to force a completely different solution only be means of writing proper tests. I wanted to try something different so I convinced Piotr to leave TDD aside for one session. We agreed to use test-first approach but implement the design I proposed. Piotr suggested that we should also refrain from writing any conditional statements (if, switch). This sounded like a fair deal.

What we tried was an actor-based approach. Every cell was an actor which was able to respond to various events. The environment was responsible for routing these events so that cells get events generated by their neighbours. The solution was turn-based so that in the beginning of each turn every cell got events from other cells and at the end — a clock event from the environment. The response for this event could be either ‘alive’ or ‘dead’.

The other interesting thing about this solution was, it allowed us to get rid of conditional statements in a quite elegant way. We used a state pattern to process the events:

public interface IState
{
   IState ConsumeAliveEvent();
   IEvent GetResponse();
}

There can be four possible states in the game: base (cell will die in next round), after consuming one alive event (will also die), after two (will survive), after three (will survive) and more than three (will die).

Unfortunately we didn’t have enough time to finish the code, but it was quite promising. Especially the tests which were in form of statements like this

given these (events) happened, the cell should generate these events

In quick summary I would like to encourage you to take part in every code retreat event that is organized in you neighbourhood. It is really worth it, event if you have some experience in TDD and/or pair programming.