Pair programming. What are your thoughts on this?

[aceO07]

I've never had any experience with pair programming before. Only times I'm in a pair is when I need help or am providing help. Anybody using this technique in their work place? What do you think of it?

 

[SJP0tato]

As with most programming methodologies (in my opinion anyways) it has situations where it's very helpful, and others where it's not. Sometimes while I'm working on something intricate and new, I'll try to have someone with at least (hopefully more) experience than myself and talk over implementation to get a different point of view on what I may have missed, or could be improved upon.

OTOH, having someone sit and code with you 24/7 to me would be like reading a book with someone else standing over your shoulder reading it too. You'd both have to read at the exact same pace, and would ultimately proceed as fast as the slowest reader.

 

[Markbnj]

Just more silver-bullet guru crap that's supposed to make it easier to create great software in the absence of requirements and resources. In every job I've had the programmers have "pair programmed" when they needed to, and "get out of my cube programmed" when they needed to do that. The methodology I think works best is "pair consulting." That's where you take pairs of consultants and tie them together back to back. Then you can gather them up and stack them like cordwood in some convenient location.

 

[Crusty]

Originally posted by: Markbnj
Just more silver-bullet guru crap that's supposed to make it easier to create great software in the absence of requirements and resources. In every job I've had the programmers have "pair programmed" when they needed to, and "get out of my cube programmed" when they needed to do that. The methodology I think works best is "pair consulting." That's where you take pairs of consultants and tie them together back to back. Then you can gather them up and stack them like cordwood in some convenient location.

:laugh:, that's a new use I haven't thought of yet!

 

[Ken g6]

All the companies I've been a contractor for seemed to be very concerned with making sure that no piece of knowledge is held by only one person. For that purpose, it sounds like pair programming could be useful. I've never done it, though.

 

[degibson]

Sometimes its good just to talk over your code with someone as you write it to make sure you're not missing something glaringly obvious. Esp. helpful for two new people learning a foreign codebase without a local expert.

 

[BoberFett]

Originally posted by: Ken g6
All the companies I've been a contractor for seemed to be very concerned with making sure that no piece of knowledge is held by only one person. For that purpose, it sounds like pair programming could be useful. I've never done it, though.

Normally that's referred to as "commenting your GD code."

 

[DaveSimmons]

Originally posted by: BoberFett

Originally posted by: Ken g6
All the companies I've been a contractor for seemed to be very concerned with making sure that no piece of knowledge is held by only one person. For that purpose, it sounds like pair programming could be useful. I've never done it, though.

Normally that's referred to as "commenting your GD code."

... and "code reviews."

The faint praise I find plausible for PP is that it helps two weak or new programmers work at closer to the level of a decent one, if their flaws don't overlap too much.

 

[aceO07]

I read this article http://www.infoq.com/articles/adopting-pair-programming earlier today, so I was curious to see if anybody here did it.

I can't imagine myself doing pair programming. It would drive me nuts not having control over the keyboard/mouse. I like going at my own pace. Sometimes I like to slowly work through a problem and give it more thought because I think it deserves more time. Other times I want to quickly code a solution. The idea that I would need to explain to someone what I'm doing and why I'm doing it would distract me. Code review is good once in a while, but pair programming on a daily basis NO THANKS.

 

[Markbnj]

It scares management that software is created by individuals. The people who have to depend on the stuff have an intense, and probably understandable, desire to transform the process of creation into one of production, because production is reproducible and predictable, all things that creation is not. But what we do meets all the definitions of an art and a handicraft, and none of the definitions of a production process. All of the tens of billions spent over the last 30 years on 4GLs, CASE tools, unified processes, methodologies, has been to try and regulate the individual creative component of programming and make it more like everything else the modern manager manages.

 

[zebano]

When we have problems, we grab another engineer and both sit down and review the code. If we still can't figure it out, we grab someone else. We've had a couple 6 - person pow-wows recently but usually 2 is sufficient. The times when pair programming is most helpful is when working on a customer problem and trying to root-cause it, the differing skill-sets usually compliment each other then. Talking things out often helps me understand my code better. That said, I would hate to do it all the time.

 

[Markbnj]

Just to be clear, pair-programming is not discussing issues with your team members, even if you do it frequently.

http://en.wikipedia.org/wiki/Pair_programming

So, in case anyone is wondering, when we pair, I'm the damn driver.

 

[PhatoseAlpha]

Meh. Sounds like the kind of thing that leads to 5% fewer bugs, 5% more productivity, and a 50% greater staff turnover rate.

 

[Madwand1]

Pair programming is a software development technique in which two programmers work together at one keyboard. One types in code while the other reviews each line of code as it's typed in. The person typing is called the driver. The person reviewing the code is called the observer[1] or navigator. The two programmers switch roles frequently (possibly every 30 minutes).

That sounds pretty idiotic to me. Maybe a good way to churn out code which is a bit better than churned out code without over-the-shoulder reviewers, but that's it. If you're coding line by line, you're just doing it wrong. You should be working primarily at a level of abstraction, and the line by line coding should be mostly trivial and highly fluid as higher-level ideas change.

Why then does pair programming put the emphasis on the keyboard and line by line instead of higher-level concepts and abstractions? Because it just doesn't contribute anything material other than the happy accident that sometimes two people work together better than one, depending on the people and the task? That is a great idea, and the first thing I'd toss would be the line by line single typist -- to me that's just a mechanical compromise avoiding one of the obvious conflicts to enforce collaboration.

 

[IHateMyJob2004]

Originally posted by: Markbnj
Just more silver-bullet guru crap that's supposed to make it easier to create great software in the absence of requirements and resources. In every job I've had the programmers have "pair programmed" when they needed to, and "get out of my cube programmed" when they needed to do that. The methodology I think works best is "pair consulting." That's where you take pairs of consultants and tie them together back to back. Then you can gather them up and stack them like cordwood in some convenient location.

It sounds liek you are describing extreme programming, not pair programming.

Regardless, pair programming has it's place. Where I work, safety critical code would never be done this way. It would be programmed by person A and peer reviewed by person B.

Anyways, I've done pair programming (along with Extreme programming) with Java and it is quite impressive when used on the right project. Doing pair programming essentially causes a peer review to be done as the code is written. The number of times that bugs were caught by a second eye are to many to mention.

In the end, we delivered near bug free code to our customer, it is easy to build on top of and the customer loves us. Oh, we usually did pair programming for JUnit, but not always. usually the more complex test code was developed via pair programming.

Seriously, I am glad that I used pair programming once. A book can tell you only so much. For example, Eclipse w/Java code makes alot of sense because the IDE allows for quick development. But to do development in MS Visual C++, I don't know if there would be an advantage. The ol' peer review process is probably more efficient.

 

[IHateMyJob2004]

Originally posted by: DaveSimmons

Originally posted by: BoberFett

Originally posted by: Ken g6
All the companies I've been a contractor for seemed to be very concerned with making sure that no piece of knowledge is held by only one person. For that purpose, it sounds like pair programming could be useful. I've never done it, though.

Normally that's referred to as "commenting your GD code."

... and "code reviews."

The faint praise I find plausible for PP is that it helps two weak or new programmers work at closer to the level of a decent one, if their flaws don't overlap too much.

Couldn't disagree more. Even strong programmers make errors.

 

[IHateMyJob2004]

Originally posted by: PhatoseAlpha
Meh. Sounds like the kind of thing that leads to 5% fewer bugs, 5% more productivity, and a 50% greater staff turnover rate.

From my experience:

Turns into 90% fewer bugs
Productivity of 1.8 men probably (can't lie, but time is saved in the long term due to less point release work to fix bugs)
0% staff turn over

---------

Alot of the comments against it sound like comments that are being made by:
1) Those that have no experience with it
2) Those that are set in their ways

I was scared crapless about using the PP methodology the first time I used it. I had some schedule concerns up front but in the end, we turned out some seriously good, nearly bug free code. There was almost a competition to find better ways to do things. It actually fostered knowledge growth.

The only error from recent memory had to do with a .properties file in Java. Well, if you forgot one defintion in the .properties file or it was poorly defined an NPE would occur. Easy fix and there was no way to catch that one in JUnit or functional testing. The customer found it though. Minor stuff though.

Also, in JUnit, 2 people can come up with better scenarios than one. Making the end product less likely to have bugs.

-----

As for switching roles, every week is fine. 30 minutes is not realistic. 4 hours would be OK though.