Global Day of Coderetreat 2016

On Saturday the 22th of October 2016 a colleague and me took the train from Stuttgart to Karlsruhe to enjoy the Global Day of Coderetreat 2016, an event to improve your craft and to have fun.

There are 6 sessions, 45 minutes of coding and ten minutes of retrospective. The rules are to use pair programming, TDD, deleting your code after every session and then to switch pairs. The idea is to have a go at implementing Conway’s Game of Life.

First Session - No constraints

Pairing with someone getting started in using TDD we spent most of the time going through the basics of TDD. Especially the usefulness of the refactoring phase, where we spent some time discussing test readability, e.g. quickly grasping what a test does. We also talked through the necessity of deleting tests when the functionality they test is being covered by other tests as the test cases evolve. Avoiding the situation of having multiple test break when we introduce errors. Making it harder to spot the exact place where the error was introduced. JavaScript was used.

Second Session - Wrap Primitives in Value Objects

Instead of passing around two integers for x and y location we were introducing Value Objects such as Location. The group retrospective of the session involved some debate on the specific time of introducing these value objects. The argument being they slow you down in the beginning. The term over-engineering was used.

I did not agree since one gets to a point pretty quickly where the combination of x and y is used as two method arguments multiple times instead of passing an object which makes it clear they belong together as the concept of location. We used Java.

Third Session - Mute Ping-pong

The third session was an eye-opener for me. My pair and me were not supposed to talk to each other during the session (apart from solving issues with the IDE). One of us had to create a failing test, the other one had to bring it to a pass and create the next failing test for the other one to bring to a pass. Communication of your intent had to happen via tests. Instead of articulating design ideas by speech one had to create a test which forces the design in a specific direction. Java was used.

At first it all seemed kind of nonsensical but at one point you realize that reading code without knowing the intentions of the person who wrote it happens all the time. Be it bug hunting in some legacy project or even an open source project. In both cases you probably do not have the original author at hand. Thus the developer should strive to reveal intent with naming her classes, methods and variables accordingly.

Fourth Session - Baby steps

We had two minutes to get from a red test to a green test. If the timer ended and we were not back to green we had to revert the changes. It was the only session where version control was used to quickly throw away uncommitted changes to the repository.

If the team had to revert on a red test they have probably taken a bigger step than they should have. A solution would be creating a test which allows the developers to go to green faster. An awesome idea to practice TDD. Following the baby step practice also means you have a state you can commit to the repository every two minutes or less. Allowing you to do proper continuous integration and to be able to step away from the code at all times, e.g. when helping someone else or going for lunch, without having to have people in need of these changes be kept waiting for one huge change at once. It was the third and last time of the day where we used Java.

Fifth Session - Pick your style of TDD

In all the session before this one my pairs and me have always used whats called Detroit School of TDD or Classicist where you do state-based tests. To use the London School of TDD we went for an approach based on mocks. A proper explanation of the two schools can be found here.

In general opts for mocks at the boundaries of the system. Say for example when reading from a database or sending out emails. In a somewhat purely algorithmic Kata such as Game of Life using mocks is not necessary. The argument my pair and I made to use mocks was:

How to develop the game of life if you do not yet know how the world is stored?

In all previous sessions it was stored in memory. For the fifth session we decided to defer the decision into the unforeseeable future and mock the state of the world. That way we could implement the four rules without caring about the structure or way to store the world. JavaScript was used.

Sixth Session - Keeping a priority list

The sixth session was pretty much the same as the fifth. Since my sixth pair was intrigued by the concept of mocks we were taking that approach. The difference to the fifth session was that we had to create a to-do list of tasks to achieve and prioritize them accordingly. We then started to cross off items on the list as they got implemented.

What I took out of the session was the idea of writing down stuff instead of keeping it around in your head. Thus you can write down a possible refactoring you spot without doing it immediately since you might be in the red phase of the cycle where you are supposed to bring the test to green instead of refactoring.

Conclusion

It was a great GDCR 2016 and I will be happy to participate again next year. Getting up at 6am on a Saturday was definitely worth it.

As a goal for next year I would list getting to use a language I do not yet know.