Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase ««12

Pair Programming Expand / Collapse
Author
Message
Posted Wednesday, September 26, 2012 10:10 PM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Wednesday, July 17, 2013 8:58 PM
Points: 28, Visits: 114
I have been doing Pair Programming since the late 80's. It was usually limited to the Debugging environment. On a weekly basis we had team discussions of the issues and helped each other from there. Then in the 90’s sometime a developer was not comfortable with the API’s and we would team up for a few hours, to help out (mentoring). Now days code reviews and debug assistance works fine for us.
Post #1365024
Posted Thursday, September 27, 2012 8:42 AM


SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Monday, June 16, 2014 2:36 PM
Points: 2,085, Visits: 323
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..


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.




Life as a DBA: Living in a box, but thinking outside of it.

Blog: www.chilledsql.com
Post #1365314
Posted Thursday, September 27, 2012 12:14 PM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Friday, July 18, 2014 9:15 AM
Points: 2,889, Visits: 1,778
I had a long discussion with a tech lead regarding pair programming and productivity. There is an aspect of you can't change a thing but you can change your perception of a thing.

The danger is that you view it as dragging your best people down rather than strengthening the weaker ones.
There are pairs who work together very well because they naturally buddy up.

One of the things with pair programming is that it encourages the rotation of pairs so Fred and Bob may pair for certain aspects of the project but Fred and Joe pair for others. The general idea is to broaden the skillset across the team and raise the skill level.

Like all things it takes some getting used to. The tech lead's take on it was that for the first few itterations productivity will go down then it will resume normal velocity. His take on it was that it didn't improve speed of delivery per se but would improve quality and make the team more flexible. The broadening of skillsets was a boost for morale.

You do need a computer with dual keyboard & pointing device and you definitely need comfy chairs and desks that support pairing.


LinkedIn Profile
Newbie on www.simple-talk.com
Post #1365439
Posted Friday, September 28, 2012 10:10 AM


Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Thursday, March 6, 2014 1:05 PM
Points: 1,334, Visits: 3,068
ChillyDBA (9/27/2012)
[quote]
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





Glad it worked well for you, and it proves that pairing works when these 3 above variables are shared by both parties. However, when you are paired for example (many times without your consent or approval) with a junior programmer from India with a very thick accent that is more interested in talking on the phone overseas all the time in a language you can't even understand, then the results can be much different. It all depends on who you are paired up with that makes the final result.


"Technology is a weird thing. It brings you great gifts with one hand, and it stabs you in the back with the other. ..."
Post #1365993
« Prev Topic | Next Topic »

Add to briefcase ««12

Permissions Expand / Collapse