Today I spent about an hour with Tom for preparing a retrospective that I am going to facilitate on Thursday. Yes, crazy isn’t it? We actually did pair planning 🙂 I think it was useful and we come up with a good plan. We started thinking about what the team did in the last two weeks. It became immediately obvious that we needed to create a themed retrospective in order to tackle a few important issues the team is facing rather than doing a more generic retrospective. Two books helped us to identify the right activities Agile Retrospectives and Gamestorming. I only read the first one but Gamestorming is definitely in my wish list. Anyway, I have access to both thanks to my Safari Book Subscription. Other useful resources to organize retrospectives are Retromat, Agile Retrospective Resource Wiki and Fun Retrospectives. Let’s see how it goes. Stay tuned.
I also worked with Matt and Peter on a fix for an annoying line ending bug. The fix is part of an internal fork of NGit that only later I learnt not to be internal. So all the code changes are public. You can see the pull request here https://github.com/red-gate/ngit/pull/17. The interesting thing is about the performance optimization and the OR operator in C#. If you do an OR operation in C# you need to make sure you use the conditional OR operator (||) and not the binary OR operator (|). They both work the same for bool types but only the first one does “short-circuit” evaluation. The fact that we used the binary OR operator made the apply patch operation a thousand times slower! So pay attention 🙂
Finally, if you host your code on Github, I recommend you to create a pull request template. It is basically a simple markdown file that you add to your repository and that Github use to automatically populate the pull request description. Having a template is useful to remind your team or anyone who want to contribute to your repository the few important things to consider and helps to catch problems. It might even contains few links to internal documentation of the team processes.
This is our current pull request template that we use in all the projects my team is responsible for. For the tests we usually add checklists. It’s useful.
## REMINDER: Have you written Release Notes?
#### What does this PR do?
A summary of the changes you’ve made and if relevant, anything you haven’t done.
Who is this work valuable for? What value does it add?
#### How is it checked?
What automated checks cover this change? Make sure they all pass.
#### How has it been tested?
What manual testing have you done?
#### What are the risks?
What is the impact and likelihood of the risk? What have you done to mitigate it?