Thoughts on pair programming (and when it makes sense)
Pair programming is a development technique used in Agile software development techniques like XP. Lots of people I know are big fans of pair programming, and many teams have everyone pairing on pretty much all coding activities. I’m just wondering if this is really the best way to do things in all situations.
To be fair, I’ve never been on a project where we paired all the time. I’ve paired off and on for various things. So I can’t really present the argument from the side of someone who pairs on everything.
There are many obvious benefits to pair programming, as you could imagine.
- Onboarding a new team member
- Senior developers pairing with junior developers
- Working together on something particularly challenging
I’m not debating the value in this kind of thing. I’m just questioning the value of doing it all the time on everything.
I’ve asked a lot of people who pair a lot why they find it to have so much value. I’ve heard various answers, some of which I’m not sure I agree with.
The hard part of programming is figuring out how to do something, not the actual typing part.
This may be somewhat true… but to what extent? For most features, I usually sit down at the beginning and think about how to design things at a high level (and often discuss it with others). This certainly is the hard part, but once we figure it out, then I have to plug through the work and get it done, and doing this design doesn’t usually take that long. At that point, I see less benefit in having someone else there watching me, especially when I’m doing mundane tasks like HTML layout, setting up test data, etc.
Pair programming is actually faster than doing tasks individually.
In order for this to be true, that means that at least 50% of my time spent doing a task individually is wasted time due to bugs, rework, getting stuck, time spent figuring things out, etc. I don’t doubt that two people working together end up with better quality code in less time. But how much better? And can you honestly say that two of you can do it in half of the time compared to one of you doing it individually? Maybe in some cases this is true, but I would think that more often this wouldn’t be the case.
There are diminishing returns to pair programming. What I mean by that is this: if you and I paired on the same project, over time we would both learn the system better, we would start doing things the same way, we would design code better, we would learn new tricks and techniques from each other, we would work better with our team, and we would become more disciplined about writing tests and not cutting corners. But as time goes on, we would also be getting better at doing these things individually. We would be able to design things better individually, we would learn to be disciplined to write tests, and we would get better and doing things right the first time.
What if we were already able to understand how to design things correctly, we were already disciplined to write tests and not cut corners, we already communicated well and were team players, and we were better at development in general? In that case, I feel like pair programming makes less sense because the value we’re getting with pairing over individual development would be less.
On every project there has to be some balance between speed and quality. On one end of the spectrum you have startups who have to ignore quality and things like automated tests to just throw something together that seems to work so that they don’t lose their funding. On the other end you have some mission-critical project like a nuclear power plant or a pacemaker that can’t afford to fail. Those mission-critical projects need higher quality, but that comes with a lot of extra cost. Somewhere is the middle are our projects.
Obviously quality is very important, and if you know me you know how much I am a fan of TDD. But TDD, pairing, and anything else needs to be justified in terms of cost (both short-term and long-term). Is what we’re doing worth the time that we’re going to spend on it? The code has to work, that’s not negotiable. But since we have a finite amount of time to finish a project, we can only sacrifice so much speed in order to make sure we have quality.
When it comes to pairing, there are a lot of factors that need to be considered, namely how difficult your project is, what the business problem is, who is on your team, how experienced they are, and so forth. I’m not saying that pairing is bad in all situations. I’ve seen it work very well on several different projects, and like I said earlier, there are places where it definitely fits.
Now I am a proponent of having all code agreed upon by more than one person. You could do this with code reviews, pair programming, or assigning features to two people (who will spend time agreeing on the design, but won’t necessarily sit at the same machine and do the work together). I just want to make sure that we don’t have to waste time due to rework. I also emphasize to people that if they get stuck on something to please please please ask someone for help instead of trying to be a hero and spending a whole day trying to figure something out just because they feel like they should be smart enough to solve it on their own.
Again, I’m not saying that all pairing is bad, or that if you’re pairing on everything on your project that you’re doing it wrong. My whole point in this is that I think we need to evaluate each situation and decide how we can best deliver a solution with a sufficient level of quality in the least amount of time possible. Maybe that involves pairing, but maybe not. But I think we have to at least ask that question.
Leave a Comment