The book Facilitating Technical Events is for technical trainers, coaches, events organizers who want to have a good event flow and happy attendees.

Brutal Refactoring Game

I wrote a post on the history of Brutal Refactoring Game, you can read it here.

In this blog post I want to tell you more about the workshop and about my experiences while facilitating it. Also I will add some tips for facilitators that want to try themselves this workshop.

The purpose of this workshop is learn what refactoring is, why it is so important to do refactoring often and immediately after you spot some coding smells. Often I ask programmers “when are you doing refactoring?”. The question has a vast number of answers from “when I think I need to”, to “once a month” to something like “every couple of tests”. But seldom I hear that programmers do refactoring all the time, in the minute the tests had passed from red to green”. This is where the format comes into place.

In my experience if I refactor late, if I postpone the refactorings I need to do, I end up with messy code. And this messy code is harder to refactor because I forgot some of the intent of why I wrote it. So this workshop is for pushing programmers to refactor often and as soon as there is a coding smell.

But here we have the following issue: spotting coding smells is hard. While facilitating this workshop I often see coding smells that are obvious to me. I ask the pair if they have anything to refactor and they say “no”. This happens way to often in my experience as facilitator of coderetreats, workshops, dojos or anything of that sort.

So this is where the difficulty of facilitating this workshop is. You need to:

• Be able to read fast any programming language
• Be able to spot coding smells in all of these languages
• Express your concerns about a coding smell fast (10-15 seconds)
• Drop the bomb (i.e. the card to block any new functionality) with the least explanation needed; be short.
• Read around 7-10 code bases (7-10 pairs, meaning 14-20 people) in the same time while you move between the desks
• Change context very often: take 30-45 seconds batches to read each one of the code bases
• Remember where every one of the code bases is heading just by reading them
• Think of possible coding smells each one of the code bases might produce
• Not involve yourself in any disagreements with the audience: you are the benevolent dictator

But do not be discouraged, all of these things can be learned. You can pair-facilitate with someone that has the experience, or you can do it the hard way and see your limits as a facilitator.

Now I would like to recommend one of the formats that works very well for this game. And I will explain why I think it works well. Give a short introduction of 15 minutes where the facilitator explains the context. It is very important to give the attendees “disagreement cards”. Then start coding for 25 minutes. Short 5 minutes debriefing. Ask everyone of they wrote any disagreement cards. If they had, discuss them first. Then go on with questions like “how did you start”, “did you have any issues”, “would you change something for the next 25 minutes session”, etc. I do 3 iterations of 25 minutes. Then I stop and we have a retrospective of the session. We discuss again what refactoring is and what is not. And of course we discuss about the benevolent dictator role: when and how it is useful.

Why is this working well? Some people will be very frustrated that you stop them from adding functionality just because there are some coding smells. If you give them a chance to explain their disagreement, they will be less frustrated during the second 25 minute session. It could be that the facilitator made a mistake and did not spot a coding smell, but rather something that was correct. It also works very well because the group learns from each other. I have done this workshop both without intermediary breaks and with 25 minutes batches. In the case of the 25 minutes batches you can see how the ideas discussed during the breaks begin to be incorporated into the code bases. So the brief discussions trigger learning, which is great!

Another thing to be aware of while facilitating this workshop: after two hours you will be tired like hell! Rest well before facilitating it and do not plan anything fancy after it, except maybe drinking beer or a glass of wine.

And the last thing: even though you are the benevolent dictator, be open and wise. Try to have an approach as if you care about the code, and you do not want to offend any attendee. Explain your every decision of stopping adding functionalities, but briefly and with care. This is very useful as we programmers all feel the code is our baby.

Update: Peter Kofler wrote a very good analysis from his experience of facilitating this game with a few teams: http://blog.code-cop.org/2017/10/introducing-code-smells-into-code.html

Subscribe