I've always been keen to try pair programming on a project but haven't had the chance until now.  Our project is a "waterfall" project that employs a number of agile practices, but this is a big leap toward a much more agile approach for future development projects within the organisation.

Over the coming days, I'll be detailing the experience with pair programming from the perspective of someone who's read a bit and is enthusiastic...but isn't convinced it's such a great idea (yet).

Pairing Begins

With very little guidance, my partner and I sat down at my workstation and started to implement a story.  I try to follow a TDD approach where I can, and so we started by writing a test that would exercise some validation rules.  I had first stint at driving, and quickly knocked up a series of tests that first failed, then passed using hardcoded return values to pass the tests.  A few mistakes corrected and then green lights all round, things moved pretty fast. 

My navigator was quick to point out a few new ReSharper shortcut keys and I was able to demonstrate a coding behaviour that I picked up (I think from a Hibernating Rhinos episode) that uses ReSharper's suggestions to their full potential.  We switched roles about every 30 mins and were progressing well until we started implementing the functions through the layers of our application.

Times Two

The function being implemented is exposed on an IIS Web server as a Web Service.  The web service exists along with two enterprise level ASP.NET web applications.  Our web service and the ASP.NET applications invoke WCF services hosted on a separate application server.  The service layer contains all but the most trivial business logic and is where our implementation started to slow down.

As we implemented service methods, it quickly became noticeable that the amount of philosophical discussion completely unrelated to the task at hand increased by several orders of magnitude.  The reason was that after every change to a service method we had to build (or rebuild) the application which takes anywhere from 20 seconds to 2 minutes, regenerate the web proxy classes each time progressed each method across the service boundary and then run our tests which took about a 2-3 minutes (almost all of that time spent waiting for the IIS application pools to start up on both the web and application servers). 

Having two sets of eyes while writing the code reduced the number of times we failed tests, but it still happened frequently enough to cause frustration.  Instead of having one resource go through this pain, we now had 2.  Since only one person was at the machine, it was 100% wasted time.  Before pairing, I would have checked and responded to an email or two, or looked for a solution to another problem while this was going on.  The wasted time due to our build and test times isn't a byproduct of pair programming, but of attempting to apply TDD to an application that isn't suited to it.  The fact that it impacted on two people just made it seem worse.

In an attempt to adjust to our environment, we started to run the tests less frequently and implement bigger chunks of functionality. As navigator again I began to start seeing opportunities for design improvement or things that we hadn't covered yet.  My thought process started to change from "do it now and the tests will cover it" to "we'll have to remember to come back to that later".  I forced myself to note down each observation that we skipped over so we wouldn't miss it later on.

4 Hours In - The End of Day One

We managed to get 4 hours of pairing in due to a couple of meetings and an informal session on pair programming from one of our agile gurus.  Overall, I was pretty happy with progress. 

We'd tried the two keyboard approach (mainly because I use a natural keyboard) with some success, but it didn't increase our productivity. 

I learnt a stack of new ReSharper shortcuts which will speed up my solo development, and felt that a few dead ends had been caught early as a result of input and feedback as both driver and navigator. 

We've ruled out TDD and ping pong as effective ways to implement our story, but that was not as a result of pairing and more of the high build and test execution times of our application.