Some weeks ago we ( the development team) were paying some technical debt, before the coding session we did some planning. While in the short planning meeting I told to my team mates that we’ll be doing our refactoring in pairs (pair programming).
I assigned the pairs and established two rounds, during each round a pair need to complete only one task per developer. Then pairs must switch. At the end of the second round if any developer had pending work he (yes all boys, boring), must complete it alone. That way during the day everyone get to work with two partners.
After my 2 to 3 minutes explanation someone asked:
– Why don we need to do pair programming?
– Because I want to force some knowledge transfer level, I said
That question got stuck in my head the hole day, first because for me the answer was so obvious and also because there were so many other reasons like:
- To learn IDE tricks
- Double checking of (complex, and error prone) refactoring
- Bounding: the sense that we are fixing “our” work, not just dealing with private garbage let by me
- Etc.
Results & Pros
- We manage to reduce the issues reported by our code quality tool by 17%
- In the process we learned new IDE tricks from peers, or discovered by laziness (trying to change more code in less time)
- We improve HTML files by removing unnecessary attributes or deprecated elements (by HTML5 spec)
- We discuss why the, cherry-picked, list of violations to fix were important and how they could affect us in the future
- By the end of the session we all agree to set apart one day of each sprint to paid old technical debt
- Now everyone is more vigilant, during code reviews, for newly introduced violations to coding standards
Cons
- Most of the time it was tedious manual labor
- Around 3 pm everyone was exhausted
- Merge conflicts: because I distributed “violations” by type, not by, physical, file or class there was a high frequency of conflicts
