Pair Programming Presented

Over the last few months, I have presented a session on Pair Programming to two User Groups (WinProTeam Rockville and PA FoxPro) and one Code Camp (Richmond this last weekend).  I especially enjoy presenting this topic for a number of reasons:

• It is not .NET specific so you can take it to many audiences (which gives different perspectives)
• It draws lots of discussion from the audience who frequently relate personal experiences
• Audience participation is mandatory by having a hands on exercise
• It is controversial (and controversial topics are always interesting!)

We *believe* in Pair Programming and have practiced it for several years now so we are not just preaching a new fad or reading from a book - meaning we also have lots of best practices to share (and funny stories).

Presentations seem to work best when the audience gets involved and is forced to think ... read: less Powerpoint slides and more paper, pens and stopwatches.  But how do you get an audience to pair program together en masse? Get them to do the next best thing:  math problems! (yeah, that is usually the response I get from the audience too).  Actually many techies do live in the strange realm of the human population who actually *enjoy* word problems, so the complaints are minimal.

How does it work?

• Pieces of paper are picked out of a hat (or promotional item) by each member of the audience.  The paper has either a pear or a gun on it.  This represents their assignment to either the group of "pairs" or the group of "lone guns".
• "Pairs" are then randomly grouped into twos and arranged to sit next to one another.
• "Lone guns" are grouped together away from the "pairs".
• Each pair and lone gun gets a piece of paper containing the same 3 problems.
• Everyone is given 15 minutes to complete the problems.  "Lone guns" must work on their own without discussing the problems with anyone else.  "Pairs" are encouraged to talk to each other but not across "pairs".
• At the end of the time, everyone swaps papers and we score the results as a group. Scores are given for responding to the question and for whether the answer is correct.
• A group discussion was then held to share ideas, impressions, observations, etc.

What were the results?

• In two of the sessions, the "lone guns" performed slightly better than the "pairs".  In the one session, the "pairs" performed 100% better than the "lone guns".
• Both groups seemed to respond to pretty much all of the questions so the differentiator was the accuracy of the answers.

Interesting observations:

• The groups always enjoyed the exercise and really loosened up to further discussion of Pair Programming techniques, benefits, challenges etc.
• Several "lone guns" expressed feeling 'left out' and wished they also had someone to talk to about the problems.
• One of the questions deliberately had a subtle ambiguity in the language - the "pairs" resolved the ambiguity more effectively than the "lone guns" who complained and struggled with the question.  One gentlemen in a session (who shall remain nameless!) complained about the question - at which point we poked fun since it seemed he was complaining that the specifications weren't clear... :-) (a pain any software developer knows only too well!)
• "Lone guns" always appeared to be very quiet and focused during the time.  Many admitted afterwards that would seldom have been able to keep up the same intensity for long periods in the workplace.
• One question involved an obscure regular expression - this was answered more successfully by the "pairs" since one of the two was more likely to be familiar with regular expression syntax than a "lone gun".
• No negative comments were received from the pairs - for example: no-one expressed that they could have solved the problems better alone.  Many positive comments were received about how much they enjoyed working on the problems together.  Some did mention that they felt like they spent a lot of time just talking about the problems.

Conclusion

Please note that my findings are hardly scientific but were mostly just an experiment to generate discussion and thinking on the subject of Pair Programming.  In this regard, they were successful since everyone seemed to enjoy the sessions and we all gained some new insights into our social problem solving abilities.

If you are interested in the slide deck, you can find it here.

For the really curious, here are the problems:

1. A User Group Pizza is cut into 12 pieces. 11 of the pieces are the same size. The 12th piece is half the size of the others. What fraction of the User Group pizza is the smallest piece?  Drag here for the answer:  1/23 (Courtesy webmath.com)
2. Each of two developers can drink a six pack of Mountain Dew in 20 minutes. Together with a third developer, they finish the six pack of Mountain Dew in 6 minutes. In what time can the third developer drink the six pack of Mountain Dew alone?  Drag here for the answer: 15 minutes (Courtesy webmath.com)
3. What is this and what is it used for?   [:]{1}[-~+o]?[)>]+   Drag here for the answer: A regular expression to find smileys/emoticons. (Courtesy Ullrich Clemenz Canaan)

Jonathan Cogley is the CEO and founder of Thycotic Software, a .NET consulting company and ISV in Washington DC.  Thycotic has just released Thycotic Secret Server which is a secure web-based solution to both "Where is my Hotmail password?" and "Who has the password for our domain name?".  Secret Server is the leader in secret management and sharing within companies and teams.