Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
Code Retreat is an all-day training event that focuses on the fundamentals of software development. There's a "global" code retreat day coming up, and I'm looking forward to it. That said, I've been to one before and have to say there was a huge amount of chaos... which is fine.
One thing that I still don't get is why the "Game of Life" is a good problem for TDD, and what good and bad TDD for it feels like.
Realize this is a pretty open ended question, so feel free to comment.
Originally, Conway's Game of Life was chosen because we had a java applet on hand to work on at the very first coderetreat in January of 2009. The goal of the day was to experiment with some ideas around time-boxed practice, and we just chose the GoL applet because we had it.
After that, though, as a couple of active facilitators (notably me during my journeyman tour in 2009 and Alex Bolboaca in Bucharest) investigated the uses of GoL as a learning tool. At the same time we were evolving the coderetreat format to what it has become today. In 2009, Alex tried at least one other problem (poker hand scoring), but didn't find it as useful as GoL. You can find more about the history at http://coderetreat.org/history
Coderetreat focuses on improving our understanding of simple design (specifically the 4 rules of simple design), test-driven development and other fundamental aspects of software development. GoL has the benefit of being a very simple problem to understand while still being very rich from a structural perspective. It readily provides parts of the system that can be used as examples of all the topics we practice at coderetreat. For example, a common implementation that takes (x,y) parameters in multiple methods is a great opportunity to talk about the DRY principle (every piece of knowledge should have one and only one representation in your system) with regards to the topology of the system. There are a lot of other aspects which can be used as examples of building a design that minimizes the cost of change.
There are quite a few people now who have done multiple coderetreats, and they still find interesting aspects of the problem to use as practice.
Conway's Game of Life would be a good fit because it's a fairly simple coding set that has profoundly powerful results. As for using it to drive Test-Driven Development, I'd wager its because the tests would fairly tricky to write because the results you are looking for are not obvious from the code you are writing. Writing code that gets you a glider is quite the trick if you've not done it before or not done it in a long time. Thus its suited to stretching the art of the discipline, particularly when executed in pair programming as TDD usually is.
As far as teaching you useful things; it's an exercise in a kind of lateral thinking. You have to conceptualize how your code will function, run it, see it fail, gather data, refactor, and continue iterating. All of these things are crucial to TDD. Linking it up to the real world, it's akin to a client handing you a vague requirements document that just says "I want X". So you give them X but getting to X might be a tricky. Conway's Game of Life is good at teaching that. It's also fairly easy to code and typically doesn't take tons of code to do so. (APL being one of the more extreme examples of implementation.) So it's quite suited for the short sessions a retreat would have rather than a week or two week iteration as you might typically find in a production environment.
Game of Life is in one hand a very simple set of rules, on the other contains some of the worst caveats of advanced programming, related to scalability. While the results are deterministic, there is the challenge of infinite playfield and infinite number of cells to process.
If the challenge specs include minimum performance and maximum memory footprint, then the tests include rapidly growing patterns, or patterns that travel in various directions far and wide, this may become a very frustrating challenge.
You got the known input and known output after X iterations, and you know all the steps to get there... except the steps take too much and too long. You must perform some pretty extreme optimizations to fit within specs. The trivial algorithm with scanning a fixed size double-buffered 2d array of bits becomes totally inadequate as its performance degrades with O(n^2) of the size. Treating filled blocks as new spawned objects suddenly eats up tons of memory and gets slow. Separating everything into limited size boards works sometimes, fails sometimes...
And since most of "global" tests will fail the performance standard, you need to develop smaller goals, smaller sub-tests that get the caveats ironed out...
It all depends on what aspect of your process you want to practice / train for.
A single day is not enough to cover all aspects of software engineering regardless of the approach / project management paradigm you choose. So to make it effective you probably should concentrate on a small subset of the whole.
If you focus on the technical aspects of TDD for example then you may want to let go the large grey areas around requirements and relations with the customer and cut right to the coding of a solution.
In this regards the Game of Life is a good candidate because it is simple, well understood and does not have many grey areas in it's requirement that will be open for debate. Thus you can start writing your test right away and code against them.
If on the other hand the goal was to see how we can use TDD to hone in on the requirements then I might have chosen the game of life but I would not have told the devs that this is what I want. Instead I would have circled around providing hints and ideas without actually mentioning it by name. That said the game of life may prove a tad bit too simple for this kind of exercise as attendees would most likely see through the ploy pretty quickly.
Examples are not always easy to find for such synthetic exercise. it has to be simple as to be done in a day yet not too simple to make it through the day. It has to be fun yet not meaningless ... But to me it has to be a bit original, I cant recall how many times I was asked to get the students to create a videoclub management system for homework.... iiirch.
