GDCR 2025: My participation summary
As every year, the Global day of code retreat is a good excuse to work and rework the same kata a full day.
This year I was the lead organizer as part as the Software Crafters Lyon, alongside with Alexis, Baptiste, and Virginie.
Subject
We choose the Yatzy refactoring kata, from Emily Bache.
Basically, the player announces a scoring method and throws 5 dices, then the dices are given to this method to be computed.
We chose it because it's wide, so if a pair is stuck with a score computation, they can skip it.
Iterations
- We have noticed that the repository was including two branches
empty_approvalsandwith_approvals - We jumped to the conclusion it was relying on Approval Tests, wrong
- It was only some basic tests (too limited)
- Attendees were stuck since programming languages setup were old
- We have also discovered that creating a golden master was involving building an output, making everything harder
- This one was to enforce "good practices"
- It was a bit odd as most constraints are applied to classes, not methods
- Attendees did not like it, but it was the most followed one
- Vox populi: immutability
- We had displayed a whiteboard before lunch where they could suggest and vote for the constraint they had to tackle
- They have picked immutability
- Since it was only local mutation, changes were easy for those who were used to it
- Mute ping pong
- Pair were not allowed to communicate (speaking, commenting)
- They also should switch the keyboard regularly
- In TDD, this constraint is easy, the first one write a test, they switch, the second writes the implementation and a new test
- In legacy, not only they cannot decide when to switch, most of them had a 3-5 minutes timers, but they don't know what was the refactoring intent of their pair
- Blind navigator
- The navigator cannot watch the code, while the driver should describe it, switch every 3-5 minutes
- Quite complicated, especially when the driver does not master the environment
- A pair has cheated, another one was relying on a piece of paper to rewrite the test, it was not their favorite iteration
- Branchless in ensemble programming (bonus)
- It was a bonus session, I have participated in this one
- It was quite refreshing
- I did this one in C#, we have refactored 80% of the functions
- There was another group in Java
- It seems they enjoyed it
Attendees feedback
(They were 20 attendees, 9 veterans, 9 people used to it, 2 beginners).
They globally enjoyed it (the ROTI were 5 * 5/5, 12 * 4/5, 3 * 3/5).
Most of the constraints were not fitting well.
The repository was in bad shape (setup & tests).
My feedback
I have given a ROTI of 3/5.
Let's start by the negative part
- Out of 31 registered attendees, only 20 showed up, probably due to the extended weekend
- The repository shape
- The constraint we have chosen
- I was really sick (I still am)
- I have not helped pairs too much
- Despite the number of organizers, they did not participate much as regular attendees
The good part:
- Most of the attendees seemed to like it
- They have all tried to adapt the constraints to learn from them
- There were a lot of discussions