Pair(ed) Programming - my hopes and expectations

Well, I've started and nearly completed my first project for '04, a project that I architected and had sign-off for late last year. This was one of the best development experience that I've ever had with regard to the following:

• meeting timelines
• producing a cool product
• developer satistaction

The project itself was a sub-component of a larger deliverable but was self-contained enough to break it out into its own spec. Without going into too many details, the purpose of the project was to allow easy creation of printed reports (PrintDocuments) for WindowsForms.

Although it would be easy to go off into a rant about how cool the code was and how cool the features were, the aspect that interested me the most about this project was that it was my first attempt at "Pair Programming". I haven't actually read any "official" :-) Pair Programming related articles as yet because I decided to have a crack at it for myself first. Some of the benefits that I was hoping to derive from Pair(ed) programming were:

• Better usage of time (2 people together are less inclined to do other things such as web-surf)
• More structured/formal usage of time
• Mix 2 programmers with different skillsets
• Pick up more bugs earlier; less test-release cycles burnt before "Golden Release"

Overall I was mightily impressed with the outcomes and believe that the Pair(ed) programming resulted in code that was visibly stronger in each of the following key areas:

• Readability - it was a focus point to ensure that all class/field/property/etc names were sensible and meaningful and that code sections - such as individual routines - were of a limited length through vigorous refactoring.
• Maintainability - 3 factors: high Readability, better use of planning time and the simple fact that the program was created by two people who have an equal knowledge of the workings of the program have led to increased maintainability
• Program structure - this leads on from the previous 2 items; I believe that because all key design decisions had the input of 2 people as opposed to one, we ended up with a much more "normalized" inheritance hierarchy and less tightly coupled modules than had been the case in earlier projects that I've worked on.

This has been an initial brain-dump of thoughts arising at the code-complete stage of development on this project. In future posts related to this project I'd like to drill-in on some of the structure that we gave to each "coding day" such as the way we enforced planning, coding and debugging sessions to be held each day throughout the development process. We also split the overall development process into 3 distinct, contiguous sections:

• Planning
• Coding
• Fixing the Coding