Being split up into two offices bears some difficulties, espescially because it’s difficult to communicate mainly via email. We try to tackle this problem by having video conferecnes each week, a mailing list to discuss programming topics, interoffice pairing etc., but sometimes it’s good to meet each other in real life. That’s why we have a DevCon (developer’s conference) each year where we talk about collaboration, code and stuff. This time we wanted to focus on clean code and get a common understanding of what we like and don’t like. Because it’s hard to achieve this by merely talking, Christoph and me came up with a coding exercise to be solved in pairs – one guy from St. Petersburg, one from Munich.
The tricky thing was that you got only one requirement after the other, so you didn’t know where all was heading – which made it necessary to refactor and redesign the code before being able to solve the next task. To make it even more difficult, laptops where switched after each task, so you had to continue working with the code someone else had written.
Each task came with a set of test cases and you were only allowed to proceed with the next task, when all tests passed. We estimated that each step would take about 30 minutes. However, some teams needed more than one hour to complete one task, so the whole exercise took us more than six hours plus two hours of discussion afterwards. But the time was worth spending, because the outcome was rather interessting:
- Sometimes a team had to continue with code that was hard to understand. Instead of refactoring it, some tried to go on with this implementation and most of the time they failed. If some code wasn’t changed for a couple of tasks, it was almost impossible to work with. Lessons learned: Take the time to refactor the code you’re currently working on, don’t start writing hacks to get things working. In theory, we already follow this approach. Plus, doing things clean is more important than doing them fast.
- One very negative thing was that almost no one did update the tests when updating the code. So the next team had to struggle with tests called ‘bookTwoRoomsWithError’ where no errors occured (because the behaviour of the code changed – but no one bothered to rename the test or eliminate it). Lesson learned: Don’t forget to change your tests if behaviour or code changes!
- Sometimes you got some code that was easy to understand just because the names of classes, methods and variables were meaningful. Because classes and methods were small. Because methods were private if no one from outside needed to use them. All those basic principles you can apply without being a genius. It’s trivial, but sometimes we do forget it.
- Working with someone you usually don’t work with (whether the reason is distance or anything else) helps you understand how this person works and gives you the possibility to argue with him what is nice or ugly code. If paring partners are switched frequently, in the end the team should have a common understanding what is clean code. We plan to do so in the future.
All in all, I’d really like to encourage you to do an exercise like this in your team. Give it a try and give me your feedback!
