Yesterday I traveled through the cold over icy pavements to the office of Mirabeau in Amsterdam to join my fellow coding enthusiasts for a day of mad coding. There I was joined by about twenty others and even eight children. The younger children set out to learn the Scratch programming language, while the older ‘kids’ went off to play with the game of life. For them (including me) the day was divided into iterations of about 45 minutes. In our first iteration we attempted to write the game using TDD as if you meant it. Which has three easy rules.

  1. The code is written in the test
  2. You may only extract a method when you get duplication
  3. You may only extract a class when several methods share the same state, that is not shared by yet other methods.

This turned out to be rather hard to do as it’s contrary to the way most of us work all the time. This iteration I joined someone who was programming in Python, as I hadn’t brought my own laptop. We didn’t get very far, as we found it rather hard to determine what our first test should do. It took us at least fifteen minutes to get started properly. In the end we only had two test methods determining whether a cell was dead or alive (although there was no real concept of cell yet) and four test methods to determine if two cell were neighbors. After the 45 minutes were done, we had to delete our test and then discussed what approached we had all tried. Some had, like us, chosen the bottom-up approach, while other had chosen a top-down approach and had started with a complete board.

As most people found this round very hard, we did another round with the same constraints. This time I joined someone who was using JavaScript. We got a bit further during this round, as we’d done some of the groundwork in the previous round. Again we went for the approach of determining if two cells were neighbors. We even got so far as to attempt to wrap around the edges of the board. But there we made a slight error in our formula while redesigning (as it was real refactoring) and had failing tests when the 45 minutes were over. Once again we had to delete our code. But when we discussed a bit more about what we had been doing, we decided that we had been going about the wrong approach and that it would be better if we had asked what the neighbors of a certain cell were, as this would be much easier to calculate and much more useful.

After the second round, it was time for lunch. But not before the children gave a little demo of what they had been doing during the morning. It turned out that what they had built on the demo laptop had not been saved properly, but the laconic answer was “Oh, no matter, I’ll just build it again.” Which is something we can all learn from, I’m sure! And indeed the demo was quickly put together again and they showed us some animals flying over the screen and turning around when they got to the edge of the screen. Very impressive when compared to our own paltry results of the morning!

After an excellent lunch I was curious about Scratch myself and so I skipped an iteration to go see what the kids were up to. They were just starting with a game of their own. They were going to make a game where a character had to catch something and would score points if he did, and lose points if he didn’t. The requirements of such a game were quickly established and written on a whiteboard. Then the kids paired up and set to write the game. After about an hour they all had most of the requirements implemented.

I left them to it, and went back to another iteration of coding. This time I joined up with someone coding in C# and the constraint was not to return anything. Which was once again quite contrary to my own coding style. And also could not be combined with the TDD as if you meant it style we had been using before. Fortunately my partner had quite some experience with delegates and we passed our one-liner assertions on to the methods under test. At the end of the iteration it turned out we had the most tests of all the groups and as we hadn’t yet deleted our code right away (as we were supposed to) we code showcase it to the rest of the group.

For the final round of the day I got to program in Java (which is the language I use daily) with the constraint not to use any conditionals. So no for-loops, no while, and most importantly no if. This turned out to be such a conceptual leap that we couldn’t really code test driven anymore. But after some pondering we figured out that you could put the conditional rules of the game in a map. Where you could simply look up the answer of whether a cell would live or die by passing in the number of living neighbors it had. We then counted the number of living neighbors by putting all the neighbors in a list and determining the frequency of living cells in it. We were sure that the frequency method must use conditionals under water, but it saved us from using conditionals ourselves. We ran out of time one final time, but at least we could save our code this time. Once again we discussed the results at the end of the round. This time the results were even more varied, as the solution really depended on what kind of constructs the language offered.

Then it was time for the kids to showcase their games and they were really impressive. One pair had created a game with a squirrel in a forest who had to catch nuts (yet avoid the spiky chestnuts). One team had a shark in the sea catching fish. The third team had created a ghost who had to catch dinosaurs. And the fourth team had a crab running to catch apples. If you want to play their games, you can at:

And finally  it was time for a last cup of coffee, a short evaluation round, a handing out of code smell cards by QWAN, and finally to say goodbye. All in all it was a great day, and I can’t wait for the next one.

(Cross-posted from the blog)