Recently, with about half of the team on vacation, it’s been hard to pair. That caused some crappy code to be produced. I personally contributed some of them. So today we had a team meeting on what we can do to improve the situation. The result was very good. We came up with a couple of things we would like to try.
- First of all, we like pair programming.
- Code review cannot replace pair programming.
- People cannot remember every piece of code they wrote.
- Code review has much less coverage than pair programming.
- It creates the wrong perception that it’s something personal because you are pretty much saying other people’s code sucks.
- It’s missing one of the (more important) benefits that pair programming offers – generating alternative ideas.
- Make pair planning/switching a mandatory part of the daily standup. Distribute the responsibility to the whole team instead of just the team lead.
- Use a combination of fix interval (one or two days) and functional point (after finishing a task) to decide when to switch.
- Will consider having a story owner on hard stories.
- A pair should not stay together for longer than three days.
That’s all I can remember for now. I think it will definitely help improving the pairing in our team.
During the meeting, one of our junior developers said that he/she would like to have some alone time fixing bugs so he/she can learn more about the system without interference. In my personal opinion it is very dangerous. In our project (actually pretty much every single project out there), a bug is not necessarily smaller than a story. New team members who tackle a bug alone might think they made a trivial change. But that change could affect quite a few other functionalities down the road. Since new team members usually need some time to get familiar with the test suite, they could end up checking in broken tests.
