How we make a code retreat at Olympic Software

Recently we organised a code retreat event here at Olympic. It was not the typical event you see during Global Day of Code Retreat, for a few reasons.

It was internal event and only people from our company were present, it was organised during work hours, and finally, it was a Legacy variant.

There were a few reasons for choosing this format:

• We knew there are a few skills that we needed to improve (refactoring, following simple design rules, writing tests and testable code, etc.). We knew exactly what issues come up in various projects and decided that getting familiar with those basics is the first step towards making our codebase better.
• Many people work long hours, so asking them to do something extra in their free time seemed a bit too much. So we tried to get some people out of a project despite the fact that for some cases it turned out to be extremely difficult, but we got an official approval to allow people to spend some time learning.
• We wanted to provide opportunity for people to practice new skills. Making a presentation, organizing a “Lunch and learn” or anything of that kind, for sure wouldn’t work.

What did we do?

• We got source code for JBrains’ Trivia game from here.
• We organized a short intro to Git a day earlier (especially useful for short refactoring sessions).
• We run sessions, each 45 min., followed by a retrospective and break. Since retros between sessions were very short, not everybody had to answer questions.
• In the end we asked every person to share what they learned, which session they liked the most and what will change in their work from next Monday.
• After that we hit the pub for a quick beer:)

How did it go?

We were surprised and very glad when people said how many new things they learned from each other. Without any suggestions on our side, a few people said exactly the things we wanted to address, regarding changes in how they would work from now on. People also got very excited about what they learned, some encountered new tools that their colleagues were using, seems like the event left them hungry for more (which was one of our two main goals).

Of course, work is much harder than what we do during retreat. In retreat we don’t have databases, the codebase is tiny, we don’t worry about deadlines and pressure from management. So I’ll follow up on this, we want to see whether people managed to implement those new ideas at work and what challenges did they come across.

Detailed description of sessions:
Session 1 : Golden Master – Create a test for the game, changing as little code as possible and covering the largest possible number of cases (challenge – change only one line). Keep the tests and use them in later sessions.

Retrospective questions:

• How much did you change?
• How many test cases did you cover?
• What challenges did you hit? How did you deal with them?

Session 2: “Make the code better” - Using whatever techniques you’re familiar with make the code look better (whatever that means to you)

Retrospective questions:

• What do you think about this codebase? What problems did you come across?
• How did you change code (e.g. extracting methods, extracting classes, removing duplicates)?
• How many tests did you add?

Session 3: Pure functions - Extract methods that do not have any side effects and state.

Retrospective questions:

• How many methods did you extract?
• What methods did you extract?
• How many tests did you add?

Session 4: Single responsibility principle - Make sure each class has a single responsibility.

Retrospective questions:

• How many classes did you extract?
• What classes did you extract?
• How many tests did you add?

Session 5: Short refactorings - There’s an imposed 3 min. limit for refactoring and covering your change with a test. If you don’t manage to finish before time elapses, revert your changes.

Retrospective questions:

• How many refactorings did you manage to finish?
• What did you learn in this exercise?
• Did you use Resharper and keyboard shortcuts?

Session 6: No mouse or short methods or eliminate conditionals - Pick one of the three tasks (or combine them:)): either do not use mouse or eliminate conditional statements from your code (ifs, switches, loops) or make your methods shorter than x lines.

Retrospective questions:

• Which task did you choose?
• How many conditionals did you eliminate?
• What techniques did you use (popular ones are using dictionaries or modulo function)?
• How many methods did you add?
• In the end, how many of your methods were longer than x lines?
• How many tests did you write?