Global Day of Coderetreat
Sunday, December 4th, 2011Yesterday I participated in the Global Day of Coderetreat. Coderetreat is an event inspired by Corey Haines who spent time traveling around the country teaching groups fundamentals of software development – asking for just enough money to make it to the next city, accommodations on someone’s couch, etc.
It is a one day, intensive. pairs programming exercise focused on Test Driven Development. CoderetreatMiami was organized by Tom Ordonez and Carlos Ordonez from Aeronautic Investments, Inc. and facilitated by Bryce Kerley and Michael Feathers.
After a brief intro, we were explained the rules for Conway’s Game of Life – basically, you have a matrix, and look through each live node. If the node has two or three neighbors, it lives, otherwise it dies. Then, you look at all of the dead nodes and if it has three living neighbors, it comes alive.
Then, we were told to choose a partner to pair with and start writing code. We chose python, wrote a quick library, some functions and did some test code to make sure our function was working as it should. We chose tuples stored in a list. After 40 minutes, we started working in unittesting when we were told that time was up, delete your code…
What? People were a little shocked. We just spent 45 minutes writing the code, delete it? Can’t save it, can’t work on it later, can’t save it to a repo, etc. Delete it.
rm -rf life/
After a few minute discussion, we’re told to pair up with another person – someone we haven’t paired with and do it again. This time I paired up with a Drupal/Javascript guy and we proceeded to write the game of life again. We didn’t get as far due to the fact that my Javascript coding isn’t as strong as my Python/Perl coding, but, we did have some tests written and had some functionality. Time’s up, delete your code. Again?!?
I then paired up with another person and we used Python. We changed our strategy a bit, decided to do a bounding box check for the alive portion to eliminate having to walk the large grid. Times up, delete your code.
We took a brief break followed by Michael Feathers showing us Test Driven Development in Ruby. Starting from an empty function with a test defined that showed him what his expected output should be. Run the test script, failure, fix this, test, failure, fix another bug, test, different results, still a failure, fix the code, test passed. Then we looked at a more detailed example of a (in his words) badly written Game of Life and he showed us a few iterations of the testing.
Time to pair up again and we’re off and running. Perl this time, however, additional condition, try to write it without IF statements. I’ve missed something because I can’t quite remember passing arrays of arrays and strings in Perl so I take a few minutes to write some test code to remember that @{$blah} gets me what I need and we’re off and running. Boolean and binary anding gets us pretty close to not needing ifs. We decide our test case code can have ifs, but not our game functions. Again, writing a test that has a few cells populated and writing the check_alive function, we get through that and start to write the check_dead routine and bam. Time’s up. Delete the code? Yes…
Another partner and this time it is PHP. While I am comfortable with PHP, we’re told, no two dimensional arrays. After some internal debate, we decide that using a transform on a one dimensional array is really just using a two dimensional array and we settle on some tricky column math and three loops to test the adjacent cells. After a bit of coding, we start writing some test functions to test check_alive, run into an Out of Bounds error because one of our test points is on the edge (a case which we talked about, but, didn’t code for), time’s up, delete the code.
On my last pairing, I am paired with someone I know. I’ve gotten the game working twice, he’s gotten it working once. He’s running a language called Processing which has a really simple IDE and ability to run the code, and, graphically display our matrix. Prior to this, all of our development has been testing code and looking at True/False tests or lists of strings to make sure they are equivalent, etc. We write our code really quickly but run into a problem with Processing’s storage of global arrays, so, we have to do a little trickery to swap arrays before the draw function. At the end of 45 minutes, we’re very close, it iterates once, goes to a blank screen, then displays the start screen again. We know it is something with the array copy (and Don ends up solving it later), 45 minutes is up… you can keep this code if you want to work on it.
Normally, they do one more session where you are paired up with your original partner to make a final attempt, but, we ran a little short on time. After a recap, we’re asked to stand up and give a brief Introduction, What we learned, What surprised us and What we’ll do differently in the future.
For me, I’ve often focused on unit tests well after the code has been written. While I don’t think I can easily change that on a number of projects, I think I will try some Test Driven Development for new code and some other projects.
All in all, it was a great experience. I met a lot of great people, learned some new coding techniques and learned a rather intriguing method of teaching. Pairs programming is good, but, for learning coding, iterating over the same problem six times in a rather intensive environment showed me other people’s thought processes in how they attacked the problem.
Many of the people looked at the problem in a much different way. One group used functional programming and maps, my first attempt used tuples and a list (and a second attempt as well which tried to solve the dead check by looking at the maximum bounding box rather than doing a complete traversal of the matrix). When we were asked to try it without if statements and in a one dimensional array, people’s thought processes changed as did the process when we couldn’t use a two dimensional array.
While there is always more than one way to solve a problem, seeing the different ways people approached the same problem, even after a number of iterations was intriguing.
Pictures from CoderetreatMiami.
Quite a fun event, highly recommended if you get the chance to attend one.
