your - why pair programming is bad




How popular is pair programming? (4)

For myself, I have started insisting that every bug I find and fix be expressed as a test:

  1. "Hmmm, that's not right..."
  2. Find possible problem
  3. Write a test, show that the code fails
  4. Fix the problem
  5. Show that the new code passes
  6. Loop if the original problem persists

I try to do this even while banging stuff out, and I get done in about the same time, only with a partial test suite already in place.

(I don't live in a commercial programming environment, and am often the only coder working a particular project.)

How popular in the world (I know that the stackoverflow community comes from different parts of the world) is pair programming? Have you ever worked, are you working or will you work for a company that does pair programming?

What's your opinion on the matter?


Have a code review before every commit (even if it's a 1 minute "I've changed this variable name"), and as part of the code review, review any unit tests.

Don't sign off on the commit until the tests are in place.

(Also - If his work wasn't tested - why was it in a production build in the first place? If it's not tested, don't let it in, then you won't have to work weekends)


I have worked in both instances where we heavily pair programmed, ones where we did occasionally, and ones where it was looked down upon.

I would say that I felt the most productive when we did it full time. This, I think, is because it encourages such a high degree of collaboration with the team. However, it was also important that we swapped pairs on a regular basis - once or twice a day. Here's some pictures of the setup at a former place:

http://www.cornetdesign.com/images/carfax

Implementing Pair Programming, however, means that you've overcome several items on the Five Dysfunctions of a Team list - primarily trust and communication. It's also helpful to be able to get into a flow - we used Ping-Pong programming - one would write a failing test, the other would make it pass and write the next failing test, with both of us participating in refactoring as we needed to.

It can be a little scary to people who are used to having their own thing, but the collaboration it allows for is really quite amazing.


We occasionally do pair programming on our team. It tends to be very productive and ends up with a lot of high-quality code, whether it was written afresh or refactored from old code.

We also have certain mission-critical pieces of code that we require pair programming or code reviews on, to try to avoid errors in logic that can easily creep up when working with a complex codebase alone.

Also, when hiring new developers we pair them up with an experienced developer for the first week or so to learn the ropes and see how some real code changes affect different parts of the system. This has proved to be a pretty good way to bring people up to speed quickly.

Overall I think pair programming is great, especially when applied in specific situations like complex code, developer education and feature exploration. That said, we only do it for probably 5-10% of our time and have a lot of productive solo time as well. Your mileage may vary.