Corporate-wide coderetreat

Yesterday we ran a big experiment for the first time.

A client we have been working with since last year for several agile and scrum trainings asked us for advice and coaching for one of their development teams. I went in for a couple of interviews to analyse their situation and biggest issues. Without going into too much detail, they were having issues with their test automation. A lot of issues. And you know what my distinguished colleague and friend Corey Haines always says: “If your test suite is bugging you, then look to the design of your code for the root cause.” And he proved right again in this statement. They had embedded C code that was strongly coupled, extremely hard to test and difficult to wrap your head around.

So we started our first legacy coderetreat sessions in the spring, focusing on clarifying naming and making duplication more visible so that we knew where and how to start refactoring this codebase. Now 4 months and 6 sessions later the team has developed an extension to Cmockery – a lightweight testing framework for C. Their extension helps you to automatically create mocks and stubs for all functions in a module. You can find their extension on github. I’ve seen a huge progress in how they develop new user stories and how they gradually improve the legacy code, taking baby steps to make their life a bit easier when they need to change existing code. Their CI build has been stable for weeks now and their reworked test suite is now a lot more trustworthy. Now back to the exiting day of yesterday. We had invited the other teams of the development department to join in for a corporate wide coderetreat. 3 other teams joined in for the session of yesterday. This meant that we had almost 40 developers spread across 4 teams and 4 different locations on the same floor. I had the good fortune of having 3 excellent co-facilitators.

Big thanks again to Cédric, Nicolas and Baudouin to help me guide all teams. It was an experiment and it was exhausting. The 3 teams that were new to the codertreat concept all had 1 designated co-facilitator and I ran from one team to the other to help the facilitators and in the mean time ask some difficult questions to some of the teams. In the morning we tried doing big retrospectives with all teams but people were really too shy to share their learning moments with the rest of the teams.

So after lunch we switched to doing team retrospectives which improved the interactions a lot. At the end of the day we did a closing with all the people that were left. We had a lot of positive feedback from the teams. The two things that stood out the most during the closing were taking smaller steps and thereby focusing on creating smaller more decoupled functions; and revealing the intent of the code you are writing. Every team had enough people left that will hopefully start functioning as ambassadors of good code design to the rest of their team. I hope that this is the start of their first community of practice around code quality and test automation. The seed has been planted, now let’s give it time to grow.