TravisDBA (9/26/2012)
Good article Steve! I have personaly done this in the past and I have found there are three basic things that can drive the overwhelming success of doing this or drive it's absolutely miserable failure. They are:1. The person's skill set.
2. The person's work ethic
3. The person's language (ie. thick foreign accent) barrier
The success or failure of these above things are all dependent on the individual person you are paired with and how they match up with the above things either individually or on all three combined.. It can all come down to you getting it done together on time, or you getting it done yourself on time, or you both end up missing the deadline. Been there, done that, got the T-shirt too..:-D
This is a pretty accurate summary of the things that made my experience of pair programming a success
Several years back I was involved in an extended data migration project moving 3 application databases with similar ancestry into a new central database. The problem here was total lack of documentation.
1. Skill set - we had totally complementary skill sets - mine was focused on data manipulation, TSQL and reporting, and hers was .Net and Business logic. While we occasionally needed to herd others into meeting rooms for group interrogation sessions, the majority of the work was completed without the need for the meeting hell that can often drag down projects.
2. Work ethic - we both had basically the same focused approach, but kept each other in check if we wandered.
3. Language barrier - I'm sure the winning attribute here was that we are both British ex-pats living and working in Canada. Not a great culture difference, but enough to make it relaxing when we didn't have to worry about translating colloquialisms 🙂
Additionally, the working environment was a big factor. As a busy (and sole) DBA and Senior Programmer in an open plan office, our respective desks were always a risky place to undertake complex data mapping or testing tasks. The management were understanding and allocated us an office for use during the 6 months of coding tasks.
Overall the project was a major success. As a bonus, the testing audit trail that resulted from our concentrated hard work is still in use 3 years later for Customer Service investigation.
Several times since then, I've worked for shorter periods 1:1 with developers on complex tasks. I've always found it beneficial as the common niggly syntax errors tend to get caught immediately. I will even seek out developers just for someone to talk at, even if they are not directly involved with the task - I've lost count of the number of times that just verbalising a problem results in a solution jumping out.