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 Tuesday, September 25, 2012 11:42 PM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: Administrators
Last Login: Yesterday @ 5:38 PM
Points: 31,368, Visits: 15,834
Comments posted to this topic are about the item Pair Programming






Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help
Post #1364440
Posted Wednesday, September 26, 2012 12:08 AM
SSC Journeyman

SSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC Journeyman

Group: General Forum Members
Last Login: Tuesday, November 18, 2014 5:10 PM
Points: 97, Visits: 343
I once did about 3 months of pair programming with my boss/senior developer at the start of a new job and I can say that it gets old pretty quickly, the comments about talking all day and being driven crazy when someone else is controlling the screen are spot on. But you do pick up mistakes quicker.

A balanced approach is great, a mix of paired work, and solo work with code reviews is better. Also if you are going to work in a pair you really need to have a room to yourself. I imagine it would be a nightmare in an open plan office with dozen of pairs going at it (so to speak!) at once.
Post #1364448
Posted Wednesday, September 26, 2012 3:12 AM


SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: Yesterday @ 2:08 AM
Points: 1,808, Visits: 1,192
Whilst being an introvert I could see this working for a few mornings or afternoons in a week. I enjoy doing that kind of joint development session. Full time though would be a non starter. I'd be as worried about being annoying long term as anything else, and I definitely need time to recover from too much close company (even people whose company I really enjoy).
Post #1364514
Posted Wednesday, September 26, 2012 7:29 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Friday, February 15, 2013 1:54 PM
Points: 113, Visits: 109
I've had limited experience with this. I worked with a ASP.NET MVP that was consulting with us. It was generally for half days and only about one or two times a week. It worked very well as I was able to absorb a tremendous amount of transfer and as any programmer knows mental block can occur at any time. It seemed that if one of us got stuck the other was able to jump in and bang out some code.

I think that used as described above for senior to junior knowledge transfer or for two strong coders working together to tackle a difficult piece of code pair programming is very useful. As any DBA would answer how much each week would be useful... it depends!



Post #1364664
Posted Wednesday, September 26, 2012 7:37 AM


SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Yesterday @ 7:12 AM
Points: 2,180, Visits: 2,173
For me the answer is very typical in our SQL community: "It depends".

If my boss asked me to work on a pair programming assignment with Paul Randall or any other SQL rock star, I'd be on the next flight to where ever I had to go to start working.

But if my boss asked me to work on a pair programming assignment with the new college intern who doesn't know how to spell SQL yet, I might not be as enthusiastic.

I know that sounds selfish but the 2 scenarios offer very different outcomes for me. The first offers me the possibility to learn from an SQL legend and become a rock star myself. The other offers me the possibility of training my own replacement and being re-orged out of a job.
Post #1364674
Posted Wednesday, September 26, 2012 7:53 AM
UDP Broadcaster

UDP BroadcasterUDP BroadcasterUDP BroadcasterUDP BroadcasterUDP BroadcasterUDP BroadcasterUDP BroadcasterUDP Broadcaster

Group: General Forum Members
Last Login: Tuesday, December 9, 2014 9:45 AM
Points: 1,446, Visits: 1,603
I've never been in a formal pair programming environment, but over the years there have been numerous times when getting two heads on a problem just made sense. In fact, when the term pair programming first popped up it seemed more of giving a name to something that should happen naturally.

There was one project where a particular ETL problem led to two of us doing extended sessions of pair programming. It was extremely powerful as we could operate at different levels of abstraction -- one on the overall strategy and algorithm the other on the detailed code. We ended up solving a problem in a couple days that had been vexing the team for weeks.

All the comments from the article made sense. Pragmatism is key.
Post #1364694
Posted Wednesday, September 26, 2012 9:23 AM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Yesterday @ 12:50 PM
Points: 2,500, Visits: 1,586
NO!

Not all gray hairs are Dinosaurs!
Post #1364782
Posted Wednesday, September 26, 2012 10:09 AM
SSChasing Mays

SSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing Mays

Group: General Forum Members
Last Login: Wednesday, December 17, 2014 9:40 AM
Points: 635, Visits: 998
As with all methodologies, pair programming can be modified to fit the environment. It doesn't have to be an all-day affair. In my past I was part of a pair where I was the new programer (not junior, but new to the company and software). My job was to install two software upgrade releases at the same time to a home-grown system - yes, they were a bit behind.

Pair programming allowed us to upgrade the install process and test the releases while at the same time training me on a system that I would be supporting for years to come. The install was the cleanest the company had ever experienced with this piece of software, and at the end of the project I was immediately able to jump into maintenance and customization work based on my experience.

We paired just 2 hours per day at the beginning, and tapered down as I became familiar with the software and the environment.

I would guess that most of us have "paired" at some time or another, it just has been an informal process rather than a formal one. In my work group we're very aware that having to explain something to another person helps clarify it in our own minds, and very often by verbalizing a problem we find the solution ourselves - at which point the other other half of the pair laughs and says "Happy to help" and off we go in our separate directions.

As with so many things, it's worth a try to see if and how it works in your particular situation. It doesn't have to be "one size fits all"; the choices on how to pair are infinitely adjustable.




Here there be dragons...,

Steph Brown
Post #1364813
Posted Wednesday, September 26, 2012 10:45 AM


Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Tuesday, September 16, 2014 2:03 PM
Points: 1,334, Visits: 3,069
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..


"Technology is a weird thing. It brings you great gifts with one hand, and it stabs you in the back with the other. ..."
Post #1364833
Posted Wednesday, September 26, 2012 10:50 AM
SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: Monday, November 24, 2014 9:31 AM
Points: 1,736, Visits: 1,072
So nobody calls it XP (Extreme Programming) anymore? This is one of the funniest things I've ever seen:

http://www.globalnerdy.com/2008/08/28/pair-programming-chairs/

I've never been a fan of XP, but I've often thought about trying my own methodology, CC, Competitive Coding. The term might turn several people off right away, but it incorporates many things that people have complained about here. Instead of working side by side all day long, two people are assigned the same task and individually go off and try to solve it. Then, time is allocated after they are both done for them to get together, review each other's code, and finally combine the best of each together for the final product.

The size of each task should range between one and three days, depending on difficulty level and each programmers familiarity with the subject.

I'm not advocating this process as a way to "keep score" between two programmers and use that for raises or bonuses. My hope would be that each person is able to bring something to the table while at the same time be able to learn something from the other person. And as many of you have already commented, be able to do that learning at your own pace.

I feel that the end result would produce a better product in the same amount of time as any other methodology. In this case, I define time as the total time spent researching, developing, testing, and debugging. I feel that because two people are working on the same task, each of them will think about it slightly differently. One may think of a possible scenario where a bug could occur and write code to handle it, where the other person did not. And vice versa. Therefore, while it may take the two programmers longer to get to the testing and debugging phase, they will spend less time there.

This probably isn't for everyone. But the analogies I often draw are partners on the police force or sports teams. I think you could build real good comradery between some developers with this approach.



Post #1364837
« Prev Topic | Next Topic »

Add to briefcase 12»»

Permissions Expand / Collapse