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.
“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.”
I think it’s important for new developers on the team to have some alone time with the code. When I started on the project, I had a hard time initially understanding how everything fit together, and it’s hard to “grok” what is going on with someone else sitting next to you who is always moving at a much faster pace. So perhaps letting a new developer work on bugs alone is not such a bad idea after all. I would propose having the new developer go over the bug fix with a pair before checking in though. That gives the more experienced pair an opportunity to make adjustments or even veto the changes altogether, say in the case where the changes are in the wrong place.
“That gives the more experienced pair an opportunity to make adjustments or even veto the changes altogether, say in the case where the changes are in the wrong place.”
That’s pretty much code review, which has its own problem. I always feel wierd telling people what they did wrong after they’ve done it.
I don’t think it’s as bad as code review. Formal code reviews involve more than two people. They involve a meeting with various people playing various roles and all sorts of rather crazy stuff. Also, a bug fix should generally represent a reasonably small amount of code, usually no more than 1 day of work. If it’s more than that, I agree that pairing may be a better way to go. Pairing is good but like I said, people do need time alone with the code. At a minimum, I propose allowing newbie pas developers to fix the bug by themselves without checking in, then to fix the bug again with a pair. The key is let someone examine the code at his/her leisure, to explore and retrace through the code, to try stuff out – effectively I start to realize to treat the bug fix initially as a spike.
I totally agree with you this time. It should be an exercise, a spike. Those code should not be checked in.