The history of “Brutal Refactoring Game”

The book Facilitating Technical Events is for technical trainers, coaches, events organizers who want to have a good event flow and happy attendees.
Support independent publishing: Buy this e-book on Lulu.

The history of Brutal Refactoring Game

Last year I was thinking about a session during which attendees would learn how to focus on refactoring. I had some thoughts about this: we would need a list of coding smells, and have some cards to give the attendees that had that coding smells in their code. Now the obvious question was: how can you have coding smells if you do not have a code base? I thought about it, and then I figured it out: during coderetreats I anyway see legacy code after 10-15 minutes. So if this session would take 90-120 minutes we would have no issue with finding coding smells.

The first thing was: of course I will ask people to do pair-programming. This is how you learn a lot!

I came with these basic thoughts to Alex, and we had a chat about this session. Initially I had wanted to print one index card for each of the coding smells. But Alex helped me simplify the concept by creating a numbered list of coding smells that would be projected on a screen. Then we thought: we could use index cards just to write the number of the coding smell.

Refactor your code commrades or it s the gulags for you

Now the question was: how do we do this? How can we enforce the coding smells? We thought about it and we said “we love clean code, so we could be something like a dictator”. Then we both had in mind the concept of “Benevolent Dictator“. The sessions was starting to shape-up. The benevolent dictator was a key factor in the environment we wanted to create: learn and play.

It was very important to present the concept of the benevolent dictator thoroughly to the audience, if not there might be danger of people considering we have something personal to them. So we decided to always say “we are not brutal with you, we just hate coding smells and want them to be gone as soon as possible”. This is a very important aspect, as it creates the atmosphere of a serious game.

Another thing we thought about was having some “disagreement index cards” where people would write any ideas they had and we disagreed on the spot. This is a very important factor, as programmers love the code they wrote. We as benevolent dictators might be wrong as well, and we need to learn from the audience as the audience needs to learn from us as facilitators. We used this cards as subjects during the retrospective of the session. Also these cards are very important because you do not want to break too much the flow of each pair and so you do not want to spend more than 40 seconds to 1 minutes at each pair. You need to understand each code base for each pair as it develops, you do have the luxury to stay a longer period of time chatting.

So we decided the programmers are not allowed to add any new functionality when the benevolent dictators tell the programmers they have a coding smell. Their priority is to fix the coding smell, call the benevolent dictator and only if he agrees they are allowed to add new functionality.

The name came from the workshop of Michael Feathers called Brutal Refactoring. You need to refactor soon and often. And this was exactly our idea as well. We want to focus during this session on having the cleanest code possible before adding new functionality.

Alex and I facilitated the first session of Brutal Refactoring Game in Timișoara almost one year ago on 22nd May 2012. We decided to use pink post-its, because they have an annoying colour. You can find here the page of this passed event. The unexpected result was that it is a very hard session to facilitate. You need to be able to read any programming language, and you need to change context every 40 seconds or so. You need to have a sharp eye for coding smells. After two hours with only seven people in the room both me and Alex were very tired.

Since then we facilitated more workshops like this. People enjoy it and some find it an eye opener to what clean code should be. So we will continue facilitating it, and hopefully any of you will facilitate it. We are both open to give you facilitation advices if needed.

A blog post will follow about the technique itself, with advices for facilitators.

Many thanks to Alex for creating this session together with me!

Subscribe

If you want to receive an email when I write a new article, subscribe here:

Subscribe for new articles

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Subscribe for new articles