This blog post has been long delayed in writing. At the end of June I attended a Code Retreat hosted by David Campey under the Cape Town Software Developer’s meetup. It was a good experience. Here are some much delayed thoughts on my experience.
If you don’t know anything about Code Retreats – take a listen to Corey Haines’ – http://coderetreat.org/about.
The day was split into 5 x 45 minute sessions with a debrief / retro after each session. We worked on Conway’s Game of Life and paired doing TDD in each session. It was a diverse group with about 10-12 attendees and a range of experience. One or two had been TDDing for years but most people probably haven’t been TDDing all day long at work. More than 50% were experienced devs with many years under their belt. Everyone was keen to Pair and TDD all day long. The energy was really great.
My first pair was with someone I’ve known since high school but I’ve never written code with before. It was the first time either of us had seen the problem so we took some time to warm up. We (I) wrote really crap code.
My second pair was with someone I vaguely know and who has been TDDing for a long time. The problem space wasn’t new to him so we dug into a side issue – which is the beauty of the problem. There are so many places to go. We looked at how to represent an infinite space and started writing tests around that. This went pretty well.
My third pair was with someone I hadn’t met before the day. This was interesting as we looked at how to abstract the space that the rules were working against. We hid them behind an interface that then implemented the 3d space. However in theory this could have been replaced by a 2d space – or perhaps a network topology – in order to implement the answers to the questions the rules were asking. We focused in on a couple of the rules. And we spent a bunch of time making the implementation beautiful. I suspect this was the best code I was involved with writing.
After each session we had a debrief / retro. That got some thoughts going as well as discussed some frustrations with what had happened in each session. This dug into some interesting interplays around fulfilling the tests vs. implementation the real workings of the code.
After the third session we took lunch and then got back to the coding. We all agreed upon 2 more sessions. The first session after lunch was to be silent coding.
I paired with someone else I had never met before. We were into silent coding so we chose to work on the most defined problem – how to represent the rules – first. This was the furthest I had got into the rules. We did some interesting stuff but got stuck on the 4th rule. Because of what we had chosen, we managed to communicate relatively well through just the tests.
The final session I paired up with someone who had been on my team at a previous company. We decided to aim for implementing the 4th rule. And we were going to try and do it without loops. That was the goal – but we got completely stuck on trying to make the 4th rule vaguely work at all. We bit off far more than we could chew with a single test and were writing code and attempting to debug it. It was a great lesson as we went for the acceptance level test and then attempted to write code to meet the acceptance level test but we got lost in the complexities of the code – and had some weird subtle bug somewhere. This showed us beautifully why you need to build up all the code in baby steps. One step at a time to get to the bigger acceptance level test. We were starting to do that at the end. It was the most frustrating session as we really didn’t succeed in any of our goals.
It took me to the second session to actually switch on into a code writing mode. This was interesting to me. Perhaps next time I should do a kata before I start in the hopes that I’ll be thinking better by the time I start.
I also realised that I generally take a little while to let something to emerge before I start to clean up the code with refactoring steps. We often didn’t get to that level of emergent code before the 45 minutes timebox ended. This makes me wonder if I should try and tighten up that cycle. Or am I slow to commit to the structure that I am seeing and do I just need more code before I can see the design and this problem isn’t going to let me penetrate that in the 45 minutes provided. That makes me wonder if other katas are better designed to emerge beautiful code designs with the problem space being are smaller. But then again – that isn’t the point! We want to be able to do something beautiful in 45 minutes. Learn how! (I suspect.)
The final session definitely highlighted the risk between just doing acceptance level tests vs building the code with the tests. That was the biggest learning for me – though I already knew it – I now have an experience to draw on to illustrate this.
I didn’t learn a lot more about TDD than I already knew from the kata’s I’ve been doing and with trying at work. But that is fine as it was really truly great to sit with other like-minded people and practice.
Some things to try in the future – though possible not in a code retreat format
Something else I’ll try next time is to articulate how I’m feeling during the session. This was a suggestion from the Design By Exploration session at CodeLab. I suspect there could be some interesting learning to be had.
I look forward to the next code retreat – with great people and trying to learn more about what great code is. Thanks to David for making these happen!