h1ghlevelb1ts

General ideas

I am on the train back to Göteborg from Emily Bache. In the final retrospect of the evening I already mentioned the following ideas to spice up upcoming code retreats 

• randomize pairs
• have multiple problems katas or at least change the problem for the next event
• offer partly implemented projects for the problems (in different languages). This way one can also practice how to evolve existing software. Challenges could be to continue projects with bad or no tests. What do you then? Green field development is great, but is not spotted so often in the wild than the extension/maintenance based development. It is important to also hone your skills of working and improving an existing code base.

Some  thoughts on TDD

The biggest focus during the whole event was on TDD. I am a strong believer in writing tests and very (very) rarely I commit a functional change without a test, however, I am not religious about whether to write tests first or not. It depends on the situation.

It was nice to to some TDD, but some things I saw still got me wondering. We implemented Conway's Game of Life and a quite common approach I've seen in the iterations was to implementing the different (arguably quite simple) game rules. Often one single rule was taken, a test for just this single rule was added and then implemented. The implementation was supposed to just pass, often by initially returning hard coded values. Then a new test was added for the second rule and the implementation changed accordingly. Depending on your level of dummy implemenations you now have to revisit again your first test and implementation, and so on ...

I am wondering whether this is really the intention of TDD. For me there is too much mocking going on. The rules for the Game of Life are quite simple and in my opinion can be implemented in one go. You can still write the tests up front, but why not write all basic tests for the four rules up front and then implement the logic? Does TDD really mean that you have to break down a problem sentence by sentence? Is it really forbidden to implement "more" than required, knowing that you will need it a few minutes down the track anyways? Part of being/becoming an expert is that you are (compared to a novice) able to manage a bigger scoped problems. Breaking down problems is good, but as with everything a balance has to be found here as well.

I also think there is still room and more importantly value in hacking/spiking sessions. Again a balance is needed. For writing production code TDD is a very good method, but it is not so suited for investigating solutions for a problem. A spike to explore the problem space can be helpful and most importantly fun. In one session I was just quickly exploring in ruby on how to actually display the game using Rmagick to generate animated gifs. It was heaps of fun and a very welcome break of all the disciplined work in the other iterations.

Misc

Last but not least, a OO thought. Due to my Java background I naturally tackle most problems in an OO way. In one session though I was the co-pilot and we went for a solution (in ruby) without classes and a very compact data structure for the problem using arrays and maps. I found even thinking about the problem was made much harder, since all was so abstract. There is a certain level of self documentation when you just see names (classes) like Cell and Habitat. It helps your brain to tackle the problem. Advanced data structures are good and maybe sometimes required, but it is definitely a good thing, if you can hide this complexity behind simpler interfaces and classes :-)

Overall a very productive and enjoyable day. Thanks Corey Haines for the idea of code retreats.

--Hardy