Refactoring Coderetreats: In Search of Simple Design

This article describes the structure, content and intentions of a typical coderetreat. From feedback gathered from multiple coderetreat events, it reflects on their strengths and weaknesses, and suggest some ways in which they might evolve in the future.

What is a coderetreat?

For the last few years, in cities all over the world, groups of software developers have been getting together at weekends to spend a whole day repeatedly trying to write code for a given problem, but never completing a solution. If you think that sounds like a form of madness, then you probably haven’t yet attended a coderetreat!

A coderetreat, for those who have not experienced one, is where a group of developers gather together, typically at the weekend, for a day of writing code for its own sake, to reflect on their craft and to learn from each other. The activity is focused on practicing the fundamentals of (agile) software development, emphasising the fundamentals of simple design, where tests drive the code, duplication is removed, the code is expressive, and contains no unnecessary features (more on that later.)

The idea was first developed by Gary Bernhardt, Patrick Welsh, Nayan Hajratwala and Corey Haines in 2009. Since then, the idea has really taken off, to the extent that there have now been three ‘Global Days of Coderetreat’ where events are held across the world on a single day, involving thousands of developers. The 2014 Global Day saw activities taking place in almost 150 cities worldwide, involving well over two thousand people.

The typical format of a coderetreat (as outlined on the coderetreat.org web site) is:

• The coding problem (or kata) to be addressed is to create a simulation of Conway's Game of Life. This simulates the life and death of cells over many generations, by applying some simple rules.
• There are five or six coding sessions, each lasting 45 minutes. With breaks for chatting, food and drink, this takes up a full day.
• Both pair-programming and test-driven development (TDD) should be used.
• After each session, all code must be deleted and partners should be swapped.
• There is no expectation that a complete solution to the problem will be written in any session.
• Different constraints can be applied to different sessions (e.g. ‘methods cannot return values’, ‘no talking’, etc.) so that both the problem space and the way you work with others can be explored and re-interpreted from different perspectives.

While this recommended format is the norm, many variations are possible, depending on the areas of understanding that the organisers of the coderetreat wish to address. For example in a legacy coderetreat, tests are created for a ‘terrible’ piece of existing code. Having said that, all of the guidelines above are chosen for good reason, so it would be unwise to diverge too far from them without risking losing some of the benefits of the activity. One aspect that can certainly be changed without undermining the basic principles is using a different kata (i.e. something other than the Game of Life.) The way that constraints are applied is also completely up to the facilitators. For example the first session might not have any constraints at all, or a new constraint can be applied half way through a coding session. The level of difficulty that each constraint imposes can also be varied, depending on the experience of the participants. When running coderetreats with students, for example, we are careful to only apply relatively simple constraints, such as ‘ping pong’, where one member of the pair (remember we always use pair programming!) writes the tests (test code only) while the other member tries to get the tests to pass (it is also a good idea to ask them to switch roles during the session.)

There are many suggestions for different types of constraint on the coderetreat web site. For example, for a more experienced group, you might try TDD as if you meant it, an advanced test driven development exercise originally developed by Keith Braithwaite. Another popular constraint is ‘no mutable state.’ You have to be careful, though. Some constraints can be problematic, in that they can bring the proceedings to a grinding halt, as we discuss later.

You may have noticed that the standard guidelines say nothing about programming language. Sometimes, a specific language is suggested, but most coderetreats work on the basis that people turn up with their own laptops, running whatever languages and test frameworks they normally use. As a result, a range of languages is frequently present in a single coderetreat, which means that you may find yourself in a pair with someone where they know the language being used, but you don’t. To what extent you find this either enlightening or frustrating is really down to personal preference and the person you end up pairing with. Perhaps it does, however, raise an interesting question about how much of our design thinking is constrained by the languages we use.

The benefits of coderetreats

What, then, are the benefits of participating in a coderetreat? In general terms, the idea is that you can explore your craft as a programmer without the usual pressures of deadlines and expectations. Not being expected to finish a solution in any session frees you up to explore new ideas, and think about how you are approaching the problem. The constant change of partners, with new and challenging constraints applied to each session, constantly gives you new perspectives on the problem, and how to solve it.

Essential to a coderetreat is the opportunity for reflection. There are brief retrospectives at the end of each session and, at the end of all coderetreats, the following three questions are asked:

• What, if anything, did you learn today?
• What, if anything, surprised you today?
• What, if anything, will you do differently in the future?

A coderetreat, then, should help to you develop your craft as a software practitioner, and give you insights into both your own and other’s practice. In essence, you should leave a coderetreat a better, or at least a more thoughtful and reflective, developer.

I, along with some of my colleagues, have been attending and running coderetreats for the last couple of years, and have also been gathering feedback from coderetreat participants using a range of approaches, but primarily on-line surveys, since these give us a global reach. The reason for doing this research was, first of all, to see if our enthusiasm for coderetreats as a means of developing insights into software design was actually justified. We also wanted to see if we could suggest ways of improving coderetreats, or at least offer some useful variations from the standard format.

From our surveys of coderetreat participants, we have seen some great feedback that suggests that, in general, coderetreats are valuable experiences. The following comments are typically enthusiastic.

• It was a fantastic experience. I would do it again in a heartbeat. I would recommend it to software development organizations. I was exhausted at the end of the day. I felt like I had a brain workout.
• A great opportunity to learn how other people might see the problem and solution
• Coderetreat is awesome. The last several I’ve attended out of a sense of duty to the profession and I always get more value out of it than I expect.
• This has to be part of the hiring process. :)

The comments above come from professional developers, but newbies are equally enthusiastic, as these comments from some student participants, show:

• It’s a good activity as it prepares the students
• I was pleasantly surprised by how useful it was
• It was really helpful and I enjoyed it a lot
• The more we did it the easier it got and getting different ideas was good

From feedback gathered from coderetreat participants from all over the world, it is clear that they succeed in helping people see that there are many different design solutions to a single problem. In fact, from studying responses to the standard retrospective question about what participants learn from a coderetreat, the most common categories of responses are that they learn (more) about:

• TDD and/or unit testing
• Other languages
• Pair programming
• Different approaches to the same problem
• Design

Clearly, aspects of design and problem solving come second only to the basics of agile development. It may be surprising to some that so many participants are still in the situation where their previous experience of TDD and pair programming is limited. However, the demographics of our surveys show that 35% of our participants had less than five years’ experience in software development, and more than 65% had less than ten years’ experience, so a good proportion of them would be students or junior programmers.

In terms of what surprises people, the following are the most common responses:

• TDD
• Programming languages and paradigms
• Working with others
• Enjoyment
• The effects of constraints

We might assume from these responses that coderetreats are doing a great job. People come along, find them surprisingly enjoyable, learn about some core techniques of agile development (TDD, pair programming) and explore different aspects of finding a solution to a programming problem through working with various design constraints. There is, however, always room for improvement. We would not, after all, be truly agile developers if we didn’t always seek to refactor our designs, and embrace change. In particular, the coderetreat community is beginning to evolve from the one-size-fits-all approach to some more focused types of event. Examples of these include legacy coderetreats (mentioned earlier) and functional programming coderetreats. We believe that more specifically targeted coderetreats can be worth exploring.

What’s wrong with coderetreats?

Although the coderetreat concept is a great one, and the vast majority of people who attend them find them both enjoyable and valuable, there are some aspects that could, perhaps, be improved. As a result of our work, we have made some observations:

1. Despite plenty of information being made available in advance, participants often turn up with little idea of what to do, or how to get started.
2. Although there is an expectation that all code is written using TDD, it often takes more than one session to get everyone using it.
3. Once you have done a couple of coderetreats, you may be looking for something different than the ‘newbies.’ In particular, you can begin to tire of the Game of Life.
4. Although coderetreats are intended to focus on the four rules of simple design, they do not necessarily achieve that in an explicit way.

We noticed from some of our feedback that the way a coderetreat is facilitated can make a big difference to its level of success, as one of our participants said:

The facilitator has a huge impact on the success of a coderetreat day and on how much the participants take home from it.

We do not believe, however, that this success is dependent only on the skills and personalities of the facilitators themselves, but the way that the coderetreat is structured. The four areas for improvement we indicated above all relate in some way to the structure of a coderetreat.

Let’s take the first problem, which is that people often turn up unprepared. Well, you can put all kinds of stuff up on a website in advance, asking people to be prepared, but it won’t actually make any difference. After all, you’re usually asking them to pitch up a Saturday, after a working week. They’ve come for something that they hope to enjoy, not for a test where they need to have done their homework. The only thing you can actually do is be more prepared yourself, as a facilitator, to get people started, and up to speed with the basic process as soon as possible.

Actually, we find that this leads straight into problem number two, which is getting everyone using test driven development. In our research, we found that in the first session, more than 10% of the pairs wrote no tests at all! In fact, it wasn’t until the third coding session that everyone was using TDD. This combination of a lack of preparedness and a slow start in TDD can, we believe, be easily addressed by providing an initial test stub, as we describe later.

The third problem is a difficult one, in that while a number of other coding problems have been suggested for coderetreats, for example business type problems like the Gilded Rose problem, which is about an inventory of products with a sell by date, or simulations of tyre pressure monitoring or game scoring, none have quite the same combination of simple problem and rich challenge that the Game of Life offers. One of our participants also mentioned the impressiveness of Conway’s algorithm.

It was my first contact with [the Game of Life] and I was surprised what amazing outcomes a simple algorithm produces.

It is clear, however, that if coderetreats are to continue to flourish and develop then we need to look beyond just the Game of Life and try out new problems. Perhaps the Boids flocking model could work, though as yet we have not tried it in our own sessions.

The fourth problem is the one that we find the most challenging. How do we ensure that coderetreats achieve their stated aim of emphasising the four rules of simple design? The results of our study suggest that this is perhaps the weakest part of the standard coderetreat structure. Although there were a number of responses to our surveys that indicated the importance of design in general terms, few respondents reflected any specific learning about the four principles of simple design, at least not explicitly. Most of our responses were rather broad, like this one.

Simplify problems leads you to get part of the solution working and a cleaner-understandable code

Such limited responses to design issues may suggest areas where coderetreats might operate more effectively.

Coderetreats refactored

From the work we have done gathering data from coderetreats across the globe, we have made some efforts at trying to address some of the issues that can detract from the experience. We structured a four-session coderetreat so that it attempted to address the four rules of simple design more explicitly, while also ensuring that participants got up and running with TDD straight away.

For the first session, to ensure that ‘tests drive the code’, we gave the participants a complete unit test and a suggested unit test. We explicitly asked them to add further code using the techniques of test driven development. For the second session, to encourage them to make their code speak clearly, we provided a unit under test, as well as some tests, but both were deliberately of poor quality. We asked the participants to refactor them both (still, of course, using the principles of test driven development.) For the third session, we addressed the design principle that duplication should be removed. Again, we provided a unit under test and some unit tests. The code contained some unnecessary duplication, and the participants were required to refactor it away. Finally, for session four, we provided some legacy code (taking our lead from legacy coderetreats) that had NO unit tests provided. The code contained some unnecessary features, which the participants were required to remove by refactoring.

We were very happy with our results, in particular with the speed with which the whole group got up and running with TDD. We don’t claim, of course, that everyone should follow our lead and run coderetreats like ours. Some might feel that our own version was so far away from the usual format that it is not really a coderetreat at all, though, in fact, we followed all the usual guidelines. What we do suggest is that, if you are a developer, you first of all take the opportunity to attend a coderetreat, if you can find one being run in your neighbourhood. If you can’t, we recommend running one yourself. It doesn’t necessarily have to be public, it can be in-house if you have enough developers in your organisation (less than ten will reduce the number of potential pairing partners.) We run in-house coderetreats with our students with great success.

If you do run a coderetreat, we suggest the following, at least for your first session.

• Don’t diverge from the standard format listed earlier in this article, apart from the suggestions below.
• Use the Game of Life as the kata for your first coderetreat, but consider other katas for subsequent sessions. You could even use more than one kata in a single coderetreat.
• If you can, decide a common language in advance and make sure your attendees know this when they sign up.
• If possible, have a room of computers set up with the required language(s) and testing tool(s) in advance (this is probably only realistic for in-house coderetreats.)
• Do provide the first test, and a suggestion for the second test. This does not have to be in code if your coderetreat is using multiple languages; pseudocode will do.
• Don’t choose constraints that are likely to kill the momentum. Novice programmers will grind to a halt if you give them ‘no loops or conditionals’, for example. On the other hand, experienced developers will relish a challenge. Play to your audience. If in doubt, give them a choice of constraint.
• Give ample time for discussion and feedback. Give people a chance to learn from each other. Don’t try to squeeze in too many sessions at the expense of reflection time.

We expect that if you engage in the coderetreat community you will come away inspired in ways that will make your approach to software development more enjoyable and ambitious. In the words of one of our participants:

I will try to have more fun and experiment more. I will also try to take the time to get better and not just do what I always have done.

About the Author

Dr David Parsons is Associate Professor of Information Technology at Massey University, Auckland, New Zealand. In addition to his academic post, he also regularly delivers professional training courses for Software Education Associates and Knowledgehut. Beginning his career in the UK, David has worked as an educator/trainer, researcher and practitioner across Europe, North America and Australasia. Prior to moving to New Zealand in 2003, he was Director of Emerging Technologies for Valtech, an international consultancy based in London. Previous roles included being senior lecturer at Southampton Solent University, trainer and consultant for Ottawa based company The Object People, and Principal Technologist for BEA Systems’ internal education. He is the author of several text books on computer programming and web application development, and has carried out extensive research into agile software development practice. He published the first academic research on coderetreats in IEEE Software in 2014. He is a professional member of the British Computer Society and the New Zealand Institute of IT Professionals.