That said I've never done pair programming. I'd like to try it just to see what it's like but I expect to get nervous having someone stare over my shoulder like a back seat driver. I've done something close like I think we all have. That is ask some one for advice and we then try and solve the problem together. You start writing code and essentially programme as a pair. The difference is that you are still the sole responsible person for the task. It didn't start out as a joint task.
So reading some one elses experience seems useful. One particular aspect I'm looking at is the economics involved. My degree included management and it gave me a passion to understand the long term value of things. Pair programming seems great for quality but you're paying two people to complete a task. So it's a bigger investment than paying one. Is the return worth it? That's a very open question that's more about interpretation and personal choice than fact.
Here I summarise what I have taken away from Pauls account so I have a good record to refer to quickly.
Prerequisites for success
There are a few nonnegotiables that are common across both of these paradigms.- Solid continuous integration - builds that run on every commit
- Talented core developers - these folks helps promote quality and drive the architecture of the codebase
- Agreement on the importance of code quality - the team and the overall company both recognize the value of maintaining a high-quality codebase
- Iterative self-organization - the team is willing to collectively evaluate their process and course-correct on a regular basis
In my experience these things are all necessary no matter what process you decide to use.
Advantages of pairing:
some of the advantages Paul has found with pair programming
- high bandwidth communication between pairs
- You can train junior developers easily by giving them an experienced pair.
- Core developers can spread best practices and knowledge silos across the team quickly.
- New tools and techniques are shared naturally across the team.
- Everybody gets better together.
Dis Advantages of pairing:
The disadvantages paul has found are:
- Pairing is sensitive to team balance: Pairing experienced people with junior and over stretch the experienced staff, It can also break down knowledge silos but also make it hard to find good pairs. One knows the area well, the other doesn't and slows the team down.
- Pairing culture can breed monoculture
- can make it tough to hire people. Not everyone likes constant pairing and working closely with the same person all the time. It can be harder to introduce different tools and approaches.
- Pairing does not lend itself to problems requiring in depth thought like system design and architecture: Particularly an experienced programmer paired with a junior. Teaching while solving a difficult problem is a particularly tough challenge.
- Sometimes you end up needing code review anyways
Advantages of code review
Paul feared the transition to code review but actually enjoyed the experience. Some benefits were:
- the positive motivating pressure to perform well is still there.
- In contrast to pairing, there are no barriers to taking on deep thought problems.
- lends itself to a wider pool of personality types that can be effective
- Code reviews are asynchronous
- forces you to think about your values more
Dis Advantages of code review
- being alone: less camraderie
- more emphasis on your own self control. You can be lazy.
- reviews and associated discussion can stack up
- conversation happens after something is built.
What's best?
My view is that they are both useful. What's best depends on the problem at hand and environment. Paul agrees. He finds both work well. His closing note emphasises the focus on quality not workflow.
So if you don’t have one already, find a team that cares about code and about process and you can try to solve some of these problems together.
No comments:
Post a Comment