h1ghlevelb1ts

Global Day of Code Retreat Stockholm 2011 - a retrospect

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

Old comments

2011-12-07Johan
Looks like you're asking for a legacy retreat ;) http://www.google.fr/search?q=legacy+code+retreat

I've never mocked anything (even though I do a lot of mocking in production code) while doing game of life. Wouldn't mind seeing a solution with mocking if you've got one around.

I wouldn't hesitate to do something else than tdd on a code retreat, after all they're for experimenting with things we don't do or do differently every day.

Finally about OO vs functional. Did you ever try using typed data, something like clojure's records? especially when mixed with protocols they provide basically the same semantic help as oo languages (with some additional beaty ofcourse :))
2011-12-08Hardy Ferentschik
> Looks like you're asking for a
> legacy retreat ;)

That's exactly what I had in mind. Thanks for the tip. I need to look out for one in my area.

> I've never mocked anything (even
> though I do a lot of mocking in
> production code) while doing game
> of life.

I did not mean a mocking framework per se. Maybe dummy methods would have been a better name. I am reluctant to call a method which is for example supposed to return an int partly implemented just because I hardcode to return 0.

> I wouldn't hesitate to do
> something else than tdd on a code > retreat, after all they're for
> experimenting with things we
> don't do or do differently every > day.

+ 1

> Finally about OO vs functional.
> Did you ever try using typed
> data, something like clojure's
> records?

Unfortunately not. It would be nice
to experiment with typed data and clojure. I am tempted to do the game of life in Erlang also, but so far only read the Erlang Getting Started tutorial. Now it would be time to get my hands dirty ;-)
2011-12-09Fredrik Rubensson
If you think about specs instead of tests it may feel better to just write enough of code to make them pass. (Even if it is a hard coded return value.) If you write more you are just speculating and putting time into possible waste. Personally I think it is more valuable to do spec first on the integration test level then on the unit test level. When unit testing - "test first" is more about driving the design and keeping complexity low.

I have been writing more black box, high level tests than unit tests lately. It is more satisfying since it gives me a clear "definition of done". Tricky low level code still always get unit tests though.

Peter Lind said that Valtech will do a legacy code retreat next year!
2011-12-09Fredrik Rubensson
Oops - forgot an insight from the code retreat. The purpose of code retreats as a concept was to get more people to do testing AT ALL. The thing is that most people coming to a code retreat probably write tests already and may learn more from doing something completely different.
2011-12-09Hardy Ferentschik
> Peter Lind said that Valtech will
> do a legacy code retreat next year!

Sweet :-)