Pair programming with Jamie Cansdale at ThoughtWork's London Geek Night last Wednesday highlighted how much I like this practice.  Geek Night is basically an open night for developers who want to work on projects (ranging from open source development, to personal hobby projects or just for those who want to experience pair programming).  Jamie and I were working on creating a Visual Studio Add-In to remove unused 'using statements' in C# files (essentially, to replicate the 'Imports Tidy' functionality provided by C# Refactory that Scott Hanselman says is almost worth the price of the add-in alone).

Here were the things I enjoyed about Pair Programming:

• Knowledge sharing.  The knowledge transfer ranges from ways of using Visual Studio ("what did you press to get that?") to how to structure unit tests ("would you split that into a second method?") and features of the object model ("how can I find the assembly that defines this type?").  Even in a short session there's a great amount of knowledge that can be transferred.
• Continuous development speed. When sharing the 'driving' seat it means that it's possible to keep developing at a constant rate.  When I develop on my own sometimes I find it hard to keep going once I've achieved a certain milestone.  In Pair Programming it's possible to sit back for a while and let the other person drive.
• It makes you braver. Pair programming provides courage to start having a go even at complex problems.  It's easier to get started attacking a problem using two heads at the same time.

We started out by discussing how to implement the functionality.  Jamie was arguing for a brute-force but fool-proof mechanism of using a regular expression to search through the code, comment out any using statement that it finds and dynamically compile the code to see if it generates an error.  I was itching to write my own stripped-down C# parse that could scan through the source code and understand the using statements (including the alias keyword and nested statements).  To settle the stale-mate by switching our focus from the implementation to the functionality.  We decided to write the tests first (yes, XP is a simple set of practices but it's easy to get off track).

The beauty of writing the tests first was that the tests were independent of the implementation.  After writing a couple of tests it became clear that Jamie's approach was likely to be 'the simplest thing that worked' in the two hours that we had.  The best part was that we were able to achieve a working implementation inside this time!

I'm still eyeing off the SharpDevelop open-source C# editor, which as C# parsing code which I'm tempted to use (or maybe it's time to get into Mono), but for now I'm sold on the value of pair programming and test first development.