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**

1) Personal Cleanliness : When you're working in a team where you are working this closely, take a shower every day, use deodorant every day, take the mints when offered. Scrum masters should be buying mints and gum, get hand sanitizer, kleenex, whatever.

The whole team may go down at once if someone gets sick. Stay home if you are sick.

2) Teams are challenged to commit at least once an hour. If not able to commit, the next hour is defined. This is committing to the master branch. (an obvious discussion of the develop and master branch is discussed.)

The pomodoro book is discussed as a manner to get short increments done. Cadence is very important.

3) TDD : If you aren't doing test driven development you are not a professional programmer. Watch Bob Martins video on test driven development. The work you are doing means millions of dollars to our business. Bob Martin is the author of Clean Code. You have a professional obligation to the code. (line 3 of the side should be refactor :-) ).

4) Pair Rotation Strategy: If we are going to beat our bus factor, we have to pair properly. A pair stair is set up to track who has paired. Different teams like to rotate at different intervals. When a story is completed can be tough (especially with multi-days) is one, also daily is another way to pair. Half days have also been attempted.

Promiscuous programming: A Team where the manager was a scientist and tried different rotational pairing. The time was very short. It could work well with the commit cycle. Data showed that it did equalize them and sped them up.

Along those lines, sharing the knowledge and raising skill level... How do you even out sharing knowledge? Teach what you are doing while you are going.

• • Live Pair Programming**

Getting Chewy Seated. Han Solo is always out front. He's all guts and glory. Chewbacca is always in the back, loyal to the guy, following him around the universe, fixing the ship... You don't want to be Chewbacca. You may hate PP because you get Chewy seated. There are three styles to overcome the antipattern.

• • Styles**

1) Ping Pong : TDD of course. Write a broken unit test. Pass to pair. Write just enough code to get the test to pass. They write the next unit test and pass it back. Green tests lead to a commit.

(an example is shown in pseudo code : BDD Statement, Assert First. An improper naming convention shows power of pairing.

If we want our unit tests to express the application we have to have enough unit tests to express the behaviour of the system. We end up with a really solid library of unit tests.

2) Board & Ball: When someone is new to the company and doesn't know the domain, this style means that one gets the mouse and one gets the keyboard. There is no navigation done from the keyboard. Only enter keys when they are agreed upon. Lesser (phrasing?) gets the keyboard. Being on the mouse can be rough. It may take a while to get used to it.

3) Batting Practice : Lesser programmer writes the code to make the unit test (written by pair) pass. This guides the lesser down a path that allows for teaching. Just enough code to make it pass keeps going. Suddenly the junior developer understands so much more and a switch to Ping Pong or Ball & Board can be done.

Statement: Implemented solutions are suboptimal. Functionality is said to not be written well.

Response: Writing unit tests in discrete functionality keeps from going down wrong path. It is self correcting. The order of the unit tests can affect the design. Ordering operations for unit tests was recently written by Uncle Bob. Also, refactoring steps may happen during the pairing.

We want to call out that we aggressively refactor as well as pair program. We are always trying to improve. It may be arrogant to rewrite code but the best thing to do is to show the changes that would be made. Trust and honesty can lead to good discussions about the code.

The term "MY CODE" is not proper. Who owns the code? The company owns it. No person does. You are trying to be nice to the next guy.

Is there something to do for a team of one? Are any of these usable individually or on a small team?

1) Get information to the people not on the team, meet and pair program.

(there may be bigger problems than paired programming)

Session End.