Pair Programming

  • Comments posted to this topic are about the item Pair Programming

  • 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.

  • 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).

  • 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!

  • 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. :crazy:

  • 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.

  • NO!

    Not all gray hairs are Dinosaurs!

  • 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

  • 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

    "Technology is a weird thing. It brings you great gifts with one hand, and it stabs you in the back with the other. ...:-D"

  • 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.

  • 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.

  • 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.

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

    Blog: www.chilledsql.com[/url]

  • 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.

  • ChillyDBA (9/27/2012)


    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. ...:-D"

Viewing 14 posts - 1 through 13 (of 13 total)

You must be logged in to reply to this topic. Login to reply