Pair programming

Question

I'm very curious, how popular in the world ( and I know that the stackoverflow community comes from different parts of the world ) is pair programming. Have you ever worked/are working/will work in a company where you've been pair programming ? What's your opinion on the matter ?

Answer 1

I have pair programmed both commercially and and at university. Its can be quite effective in keeping you on task, and generally improves quality of code more than productivity due to the "No that way sucks!" arguments you have. The biggest problem can be convincing upper management that its a good idea though as they tend to just see it as a halving of their utilization figures.

Answer 2

I've done some Pair programming (mostly professional) and I'm a huge fan of the method. Pair programming is great for new employees; That way they will get in to the company's coding standard and habbits very quick, they get to know their collegue's very well and the colleague's of this person will learn new stuff as well. As mentioned by Vagnerr, the biggest problem in professional Pair programming is getting the management on your side.

Answer 3

This answer lists pair programming as a way to teach junior programmers how to write tests and become better programmers.

I think pair programming is a great way for both developers to become better programmers.

Answer 4

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.

Answer 5

G'day,

I've used pair programming in a several of contexts. All of which are commercial BTW.

I have learned a lot from working with people with more experience.

The attitudes of the people involved heavily affect the effectiveness of the pair-programming. There's no way it will work if you are trying to pair with an agressive "I know everything and you know nothing" type of person.

For a good discussion on the different types of pair-programming have a look at Laurie Williams and Robert Kessler's book "Pair Programming Illuminated".

This book is also an excellent source of information on the economics of pair programming.

cheers,

Rob

Answer 6

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.

Answer 7

I've had negative experience with Pair Programming. You need programmers of similar experience to make it worthwhile. You put the best with the worst and the worst will allow the better to write all the code with little or no input. You put the best together and the worst together and the best will still produce high quality code, but the worst will produce shit but only 50% less (since there is only two of them polishing the turd).

Answer 8

Currently working with company that uses a lot of pair programming

I think Pair programming is great becasue it has improved me as a developer in the following ways:

• Got to know the IDE better so I could work faster and smarter (big love for eclipse quick fix!)

• Stopped me doing stupid things

• Could get up to speed on massive code base very quickly

• When starting a new job you get to know everyone you work with

• Have mentored Junior programmers effectively passing on my wisdom [sic!]

• Increase Language knowledge

• Improve Programming skills

Answer 9

There continues to be more research done on pair programming over time. Initially, reports seemed to support the notion of it being a net productivity advantage to the project in certain cases, but more larger scale and more recent studies indicate that it is a net loss in overall productivity on average for coding activities in particular.

If you think about it, it kind of makes sense. Pair programming activities have to be two times as efficient over the life cycle just to break even with the doubling of man-hours involved. My take would be just to find better engineers and practice the normal forms of mentoring to develop less skilled engineers. You get way more benefit per unit time in my opinion.

The Wikipedia entry for Pair Programming references some of the research that I am alluding to above.

Answer 10

I want articles of sunchronous and asynchronous pair programming

Answer 11

My experience is that pair programming really helps improve quality.

But, and this is very important: At least one of the programmers must have a keen eye for quality and understands agile values. Otherwise, there is huge risk that the two persons reinforce only their negative practices (ie. quick hacks etc) in each other instead of learning good practices.

Answer 12

I did that more than 30ys ago, when writing ISDN protocols for a telco company (it was not called "pair programming" then, but we were called "the unix twins" by our project manager. As we were hired as consultants, the IT managers were sceptical initially, as you can imagine. But then they liked the idea and actually kept it running for a while even after we left (as I was told by the guys who took over our code).

I still use it today (no longer for C kernel code, though)

PS: I remember one very moment, when I went ill and had to stay in bed for a week or so. When reappeared, my buddy sync'd me in a 10 minute briefing, telling me what he did and why, and then we continued as usual. There was not a real interruption while I was away as both of us were able to back up the other (the bug statistic went up a bit during that week, though)