A Legacy Code Retreat Session, part 2 - Heads up and Preparations
Links to other parts of this series:
A Legacy Code Retreat Session, part 1 - Introduction
A Legacy Code Retreat Session, part 2 - Heads up and Preparations
Just some words of warning, as there be dragons ahead.
In order to conduct a successful Legacy Code Retreat, you do not necessarily have to know your attendees - in fact, it is rare to host a session whose attendees you know. However, this does not mean that you should not collect some information beforehand. What we've done was asking people who'd attend their preferred programming languages in advance. This let us gauge interest in the different languages for the session, an was an important factor for both pairing reasons and preparation reasons.
On the other hand, do ask the participants to come prepared! Wasting the first half an hour to set up a usable development environment for everyone does not make sense. Have a computer for every pair (either provide them or agree with the attendees on who brings their own - make sure that people are comfortable with leaving their machine with their peers without sitting next to them), set those computers up with the necessary tools for the programming language they will be used with. Have the necessary editors/IDEs in place, have a git client.
Make sure your partitioners know basic git. If there are some who do not, have a git basics quickstart before the first session, don't waste the time of other partitioners who already know git.
Fork the original repository, and use your own fork as the baseline for the sessions. You might want to make changes (I've modified gitignores, and made some source code changes as well - see later for the details).
Generally speaking, you should be at least vaguely familiar with the development environment of the language(s) your participants are going to work in. You should be able to recommend a couple of tools, like a unit testing framework or a code coverage tool - however, it's more than possible that some of the developers in attendance will be way more familiar with these tools, and they can share this knowledge with the rest of the group, saving you some preparation work. The exact list of tools will vary depending on the details of the focus of your code retreat, e.g. if you aim to introduce acceptance tests in some form, you certainly should have some sort of acceptance test framework ready for the development environment your participants are going to use.
You should be familiar with the exercise. Know the domain, the business rules, the bugs, the mistakes, generally be a business expert on the trivia game. This guide will point out the most important points, but nothing substitutes doing the refactoring yourself. Spend the time on the code, get to know the code, get a feeling on what you are asking your participants to do.
You should certainly check out the source code for the specific languages your participants will be working with. The code is rather similar for most of the languages in the repository, and it includes very similar stylistic mistakes and bugs, there are variations, language by language. You might even want to change the original source code to something more to your tastes - for example, I noticed that an indexing bug and an intentional typo in the original code were not present in the JavaScript code, so I manually had to introduce them to the codebase for the sake of consistency with the other languages used during the session. Similarly, in the C# codebase, the method names' capitalization is messed up on purpose (method names are lowerCamelCased, while the language convention is UpperCamelCase), but this mistake is not introduced in the Java code, so I've decided on adding it (in Java it should be the other way around).
You might also want to look into the quirks of some of the languages. I was astonished to learn that JavaScript's random does not accept a seed, so in order to have a seedable random function, you (or more likely your participants) will have to write your (their) own. You certainly won't be able to cover all the ground in this regard, but after a few surprises, you'll certainly remember some of the funny details for your next session - don't be afraid to learn yourself from the session you conduct.
Make sure to ask the participants if they have ever done a Legacy Code Retreat before. They might know the code, remember some things from before, and might be looking for a different kind of challenge.
Make sure you have some optimistic and pessimistic plans. Some of the pairs will be slower or faster than others, and you don't want to bore them, while others are still at work. Have some extra assignments handy for each part of the session. On the other hand, be strict about timing. Some code might be thrown away at the end of the session if it does not run. Try to make your sessions depend on only a few critical pieces, anything but that goes awry, just have the participants throw it away. For this very reason, make sure your participants commit often - like very often. Anytime their tests are green, they should commit. Whenever they add a new test, they should commit.
Make sure you have enough time between the sessions for:
Hopefully, after all the preparation steps, you feel confident enough to get started with the code retreat. In the next post, I'll get into details about the introduction session.
A Legacy Code Retreat Session, part 1 - Introduction
A Legacy Code Retreat Session, part 2 - Heads up and Preparations
Just some words of warning, as there be dragons ahead.
In order to conduct a successful Legacy Code Retreat, you do not necessarily have to know your attendees - in fact, it is rare to host a session whose attendees you know. However, this does not mean that you should not collect some information beforehand. What we've done was asking people who'd attend their preferred programming languages in advance. This let us gauge interest in the different languages for the session, an was an important factor for both pairing reasons and preparation reasons.
On the other hand, do ask the participants to come prepared! Wasting the first half an hour to set up a usable development environment for everyone does not make sense. Have a computer for every pair (either provide them or agree with the attendees on who brings their own - make sure that people are comfortable with leaving their machine with their peers without sitting next to them), set those computers up with the necessary tools for the programming language they will be used with. Have the necessary editors/IDEs in place, have a git client.
Make sure your partitioners know basic git. If there are some who do not, have a git basics quickstart before the first session, don't waste the time of other partitioners who already know git.
Fork the original repository, and use your own fork as the baseline for the sessions. You might want to make changes (I've modified gitignores, and made some source code changes as well - see later for the details).
Generally speaking, you should be at least vaguely familiar with the development environment of the language(s) your participants are going to work in. You should be able to recommend a couple of tools, like a unit testing framework or a code coverage tool - however, it's more than possible that some of the developers in attendance will be way more familiar with these tools, and they can share this knowledge with the rest of the group, saving you some preparation work. The exact list of tools will vary depending on the details of the focus of your code retreat, e.g. if you aim to introduce acceptance tests in some form, you certainly should have some sort of acceptance test framework ready for the development environment your participants are going to use.
You should be familiar with the exercise. Know the domain, the business rules, the bugs, the mistakes, generally be a business expert on the trivia game. This guide will point out the most important points, but nothing substitutes doing the refactoring yourself. Spend the time on the code, get to know the code, get a feeling on what you are asking your participants to do.
You should certainly check out the source code for the specific languages your participants will be working with. The code is rather similar for most of the languages in the repository, and it includes very similar stylistic mistakes and bugs, there are variations, language by language. You might even want to change the original source code to something more to your tastes - for example, I noticed that an indexing bug and an intentional typo in the original code were not present in the JavaScript code, so I manually had to introduce them to the codebase for the sake of consistency with the other languages used during the session. Similarly, in the C# codebase, the method names' capitalization is messed up on purpose (method names are lowerCamelCased, while the language convention is UpperCamelCase), but this mistake is not introduced in the Java code, so I've decided on adding it (in Java it should be the other way around).
You might also want to look into the quirks of some of the languages. I was astonished to learn that JavaScript's random does not accept a seed, so in order to have a seedable random function, you (or more likely your participants) will have to write your (their) own. You certainly won't be able to cover all the ground in this regard, but after a few surprises, you'll certainly remember some of the funny details for your next session - don't be afraid to learn yourself from the session you conduct.
Make sure to ask the participants if they have ever done a Legacy Code Retreat before. They might know the code, remember some things from before, and might be looking for a different kind of challenge.
Make sure you have some optimistic and pessimistic plans. Some of the pairs will be slower or faster than others, and you don't want to bore them, while others are still at work. Have some extra assignments handy for each part of the session. On the other hand, be strict about timing. Some code might be thrown away at the end of the session if it does not run. Try to make your sessions depend on only a few critical pieces, anything but that goes awry, just have the participants throw it away. For this very reason, make sure your participants commit often - like very often. Anytime their tests are green, they should commit. Whenever they add a new test, they should commit.
Make sure you have enough time between the sessions for:
- briefing: at the start of each section, you'll be introducing concepts and techniques to the group. You'll also be providing them with some pointers and requests on where to progress during the next session. You might pose a challenge, have an explicit feature request, or showcase a technique and ask the participants to follow up on your example.
- retrospectives: a few minutes to talk about the previous session, reinforce some key concepts that were practiced, some techniques that were introduced, or the possible shortcomings, gotchas of said techniques
- a ten-minute break before you start the next session
Make sure you have a lunch break. The best option might be providing lunch for the attendees, and making lunchtime an occasion for networking, discussing the experiences and opinions on the code retreat up to that point.
Hopefully, after all the preparation steps, you feel confident enough to get started with the code retreat. In the next post, I'll get into details about the introduction session.
Comments
Post a Comment