At Made, we’re always looking for ways to improve the quality of our code, and anything that can help us do that while also encouraging us to solve problems as a team is something we want to spend time trying out.
The Idea
A recent Code Climate blog post introduced us to the concept of mob programming, the basic outline of which is:
- The whole team gathers around a single display
- A piece of code in need of refactoring is selected from an existing project
- As a team, refactor the code as much as possible in an hour
- There’s no pressure to create production ready code, instead the focus is for everyone to pick up best practice habits on code formatting from everyone else
The Setup
The meeting room at Made is home to a swanky HDTV, perfect for the whole team to gather around. We had one person share their laptop screen with the TV (using an Apple TV), and we then began discussing what the problems were within the code, and how we could begin tidying it up.
To encourage collaboration, we experimented with ScreenHero, a piece of software designed for remote pair programming, so that anyone who wanted to could join the screen and help refactor the code.
The Mobbing
We chose to refactor a delayed job within one of our Rails projects, and the hour flew by, with debates springing up over whether a method was too long (they usually were), whether they could be named more aptly (they usually could), and how best to refactor the code out in ways that reduced complexity and increased readability.
At the end of the hour, out of necessity, we’d extended the scope of the session to include a slight refactoring of a model associated with the delayed job, as we found there were one or two methods that ought to be contained within the model rather than the delayed job.
The code was certainly not production ready, especially given that we’d forgone TDD for the sake of speed, but we managed to significantly refactor the code in a relatively short space of time, into something we all felt was at least on its way to being an improvement over the original code.
The Future
Overall, mob programming proved to be enjoyable and informative, so we’ll be running a session every other week, fine tuning the format where needs be as we go. In this week’s case, there was one area that needed tweaking in particular, and that was making sure everyone had a chance to engage with the code.
Since ScreenHero limits the amount of users sharing one screen to two people, the freeform nature of the session, where anyone could pipe up and ask to join the screen, wasn’t the best approach, as the more experienced members of the team naturally had more ideas and could contribute a lot more.
In hindsight, future sessions will have team members rotate and spend an equal amount of time at the keyboard, so that everyone has the opportunity to express on screen either their own ideas or those that are flying around the room. The main aim of these sessions is to learn collaboratively, so we want to encourage everybody to get involved.
Also, in the weeks between mob programming sessions, we’re going to be running a Code Dojo. The aim of those sessions will be to challenge ourselves in a similar fashion to mob programming, the difference being that instead of scouring our existing projects for code in need of refactoring, we’ll be coming up with solutions to hypothetical problems that can incorporate TDD.
About the Author
Software Engineer at Made Tech
