Pair programming is something that I've been practicing for over a year now. I had never heard of pair programming before working for my current employer. I remember discussing it in my interview and being nervous as to whether I would really like it every day. Previously I had collaborated with other developers but it was a brief on-demand activity and wasn't a daily activity.
I pair for about six hours every day with a couple hours for personal improvement and administrative tasks. We change pairs every few days so we get a chance to work with everyone. One person will drive and the other person will be the navigator. However at any point in time we may switch roles. Sometimes we choose to not too pair because the task doesn't lend itself to pairing. Sometimes we have team members gone so there are an odd number of people so we'll have one pair and then the odd person out will just develop on his/her own.
| Benefits of Pair Programming | |
|---|---|
| Rounding out of skills | I've learned so much by being a navigator. Lots of little things which make developers more efficient like shell commands, shortcuts, and alternative ways of doing things. I've learned a lot about designing and implementation of code and how people have different approaches. The ultimate shadowing experience would be to pair a fresh developer with a more experienced developer. |
| Automatic code reviews | Never again do I have to worry about having formal code reviews and getting the code refactored after the review. The navigator will automatically suggest things as we go along and refactor as we go which is much easier. Also the navigator writes down a list of things to think about and possibly refactor in a separate commit so we don't try to do too much in any one commit. |
| Team Building | The more we pair the better we work together and we learn what the other team members have specialized knowledge in. We also tend to grab lunch with the person we are pairing with which gives you a chance to socialize and get a chance to know how them better. |
| Better Quality | The navigator usually keeps the driver honest and follow proper practices like test driven development and resist the urge to just hack out some code. The navigator can usually spot some outright errors while the driver may be too concentrated on coding and overlook them. |
| Better Communication | While driving I usually find myself just generally explaining the approach I'm taking. It's a much different skill to be able to explain what your doing to another person. Then as the navigator sometimes if I don't understand the approach or think there might be a better one I'll ask the driver to explain his/her approach which generally leads to some sort of design discussion. |
| No Single Person Projects | Lets say that John is the only developer who has worked on Project X developing it. This happens on small or old projects which nobody want's to work on them or you have regular turnover. While it's great John has taken on Project X it is also a huge risk if nobody else understands the code. If John get's hit by a bus (or a more positive view he wins the lottery) or leaves the company then the next person who takes it over can be in for some huge pain. Not only the next person but what if the person who takes over for John can't address issues and the system goes down. Then it becomes a business risk depending on the business impact of not having access to Project X. These single person projects also seem to get proper attention and degrade quickly in my experience. These single person projects also give John an elevated feeling of importance because now he's a subject matter expert. By pairing you reduce the risk to the business and to the next developer to take over the project. If John was paring with Brandon and John leaves then Brandon can continue on without him and they should have about the same relative knowledge. Then Brandon and Jim can be the new pair and the cycle continues. Also by pairing I believe you can delay and possibly prevent the degradation and neglect aspect which would eventual lead to some sort of re-write. |
| More Efficient | It may seem counter-intuitive to have a developer only spend half his time coding which would lead to a fifty percent drop in productivity. This is a rather naive notion because developers do not just develop new code. They also design, fix bugs, mentor, and review code. These activities also need to be done. If you are cutting corners and not doing all these activities then you are getting a false sense of productivity and in the long run you are spending more time and money than you would otherwise. When you pair these activities are an integrated approach instead of an after thought or a step by step approach. Pairing leads to a better design and less defects. This means the apparent drop in productivity early in development is offset by using less time for testing and releasing bug fixes. A better design it leads to the ability to respond to change and incorporate new features without a huge refactoring. A defect that never makes it way to testing or production environments is the cheapest to fix. In considering all the activities a developer does and not just developing new code that you are actually making better use of everyone's time by pairing. |
The only downside I can think of is pairing kind of requires both developers to be co-located. I don't know how it would be possible to pair program if you were working in a different locations. If somebody has a good approach for this let me know.
Surprisingly I enjoy pairing and I'm not sure I'd ever want to go back to not pairing. If you can pair then I'd strongly urge you to try it for a year and see how it goes.
