Pair Programming

Question: My team is half here and half in India.

A: Skype?

Sometimes the overlap is two time zones. You have a difference that is hard to overcome.

A: Teamwork work it out.

Stories should be split...

Inline QA can have a problem qa'ing two stories. That can be challenging.

The topic is restated. How to do paired programming well and pairing is caring is combined.

The group is asked how often they pair. They are asked if they think they are good. 2/3 of the audience says they could do better.

Is there a strict definition of paired programming?

There is a book on PP. It is kind of old school and rather academic. There is a whole book on PP that introduced antipatterns into the industry. People tried and got turned off.

(a presentation is brought up)

Why don't people want to pair? From Group: 1) Hygiene 2) It can be slow 3) People don't want to learn

From Presentation: 1) I can get more done myself 2) Watching someone else type is boring 3) Slackers get a place to hide 4) I like computers, not people 5) I don't work well with others 6) Desk not big enough 7) Everyone should be in their cubes so we can call them. 8) Compliance requires changes be by one person.

The point is I've heard a lot of reasons.

Fear is understandable. Keyboardists are different.

Reasons TO do it:

1) Two heads are better than one. When talking about how to solve a problem it is often found that problems are solved faster. Talking to someone else about it helps, even if it is a rubber duck. Generally people have learned to solve problems different ways.

Question: Are there guidelines? Different approaches may or may not be right.

(Let's come back to that)

2) The solutions that we come up with are better. They tend to last longer and have fewer bugs. Errors are caught as they are being written. The cheapest time to fix a problem is when the problem was introduced.

Statement: A problem where people are looking at code at different times.

Question: If I understand correctly, the way to pair is to sit next to each other. Heavyweight and Lightweight?

(Let's come back to that)

3) People are happy. My ease and joy at work is greatly improved when I do paired programming. I may be more tired at the end of the day because I paired all day but I am a much happier person and contributor when I have been in a social interaction session all day.

4) Bus factor. There is a notion that if someone leaves the company (or gets hit by a bus) then we would be screwed. Using PP is good for the company because there are multiple people aware of the code.

5) Covering people who are out. Pairing helps to share knowledge so that when someone is out there is someone there.

Our JavaScript guru left so an intern was trained. The intern then left. No one picked up on this when the first person left.

Point: Unit testing is the documentation of your code.

Counterpoint: You still have to be able to find the test and interpret the test code.

6) Mindmeld. Knowledge sharing and knowledge transfer. "Before Jimmy leaves he will write down everything we need to know." - Just doesn't work. The only one that seems to work is PP to create sustainable knowledge transfer in people.

Statement: There is a slippery slope of only pairing some of the time. Selling it is not always easy. You will produce 130 percent of the functionality that you would with one person alone.

• • GET READY**