Loading ...
Sorry, an error occurred while loading the content.

Pair programming - when it does (not) make sense

Expand Messages
  • strazhce
    Hi. We ve been doing pair programming recently (see may previous posts). It s new for us, so we discover some interesting things. One thing is: when does it
    Message 1 of 9 , Jul 29, 2010
    • 0 Attachment
      Hi.

      We've been doing pair programming recently (see may previous posts). It's new for us, so we discover some interesting things.

      One thing is: when does it make to pair program and when it doesn't.

      When it does: for us clearly when there is a huge knowledge difference between two. When one needs some knowledge and the other one doesn't.

      When it doesn't:
      - programming database access - it seems this task is so mechanical, that it is not worth to pair program (we use stored procedures only for DB access - customer policy, so writing SP + Spring SP wrapper for it is a lot of mechanical work
      - this can't be TDD very well - we use dbunit, so we need some data first to create baseline XML
      - basically every time, when one person is just watching and can't add value for some time

      Do you have any ideas:
      1. when it does and doesn't make sense to pair?
      2. is there a way to fix things above?
      3. any feedback on those issues

      Thanks.

      Oleg
    • Adam Sroka
      ... Or when neither has the knowledge, because: 1) It is easier to learn when you have someone to help you. 2) It is easier to reinforce new habits (Like when
      Message 2 of 9 , Jul 29, 2010
      • 0 Attachment
        On Thu, Jul 29, 2010 at 2:41 PM, strazhce <infobox.oleg@...> wrote:
        >
        >
        >
        > Hi.
        >
        > We've been doing pair programming recently (see may previous posts). It's new for us, so we discover some interesting things.
        >
        > One thing is: when does it make to pair program and when it doesn't.
        >
        > When it does: for us clearly when there is a huge knowledge difference between two. When one needs some knowledge and the other one doesn't.
        >

        Or when neither has the knowledge, because:

        1) It is easier to learn when you have someone to help you.
        2) It is easier to reinforce new habits (Like when you are just
        starting to write the test first) if someone is there to remind you.
        3) I don't have the citations of the top of my head, but studies have
        shown that we solve problems more effectively when we talk through
        them with someone else.

        > When it doesn't:
        > - programming database access - it seems this task is so mechanical, that it is not worth to pair program (we use stored procedures only for DB access - customer policy, so writing SP + Spring SP wrapper for it is a lot of mechanical work
        > - this can't be TDD very well - we use dbunit, so we need some data first to create baseline XML
        > - basically every time, when one person is just watching and can't add value for some time
        >

        This is true. Mechanical tasks are not ideal for pair programming. Of
        course, mechanical tasks are not the best use of a single programmer's
        time either. Perhaps you should consider automating them? And perhaps
        a pair could figure out how to write that automation more
        quickly/effectively than an individual?

        There are also times when you don't know what you are doing and need a
        minute to read the docs. This is best done individually, but it might
        be worthwhile to keep such activities brief and get back together to
        discuss what you have learned sooner than later.

        One more thing: never, ever tell people that they have to pair all the
        time. Imposing practices is generally problematic, but this is one of
        the worst ones to impose, because it all but guarantees that one
        person will do the work while the other daydreams.
      • George Dinwiddie
        ... If it s a *lot* of mechanical work, then it seems like there s a problem. ... Hmmm... I ve used dbUnit to TDD db access quite a bit in the past. I ve just
        Message 3 of 9 , Jul 29, 2010
        • 0 Attachment
          On 7/29/10 5:41 PM, strazhce wrote:
          > We've been doing pair programming recently (see may previous posts).
          > It's new for us, so we discover some interesting things.
          >
          > One thing is: when does it make to pair program and when it doesn't.
          >
          > When it does: for us clearly when there is a huge knowledge
          > difference between two. When one needs some knowledge and the other
          > one doesn't.
          >
          > When it doesn't: - programming database access - it seems this task
          > is so mechanical, that it is not worth to pair program (we use stored
          > procedures only for DB access - customer policy, so writing SP +
          > Spring SP wrapper for it is a lot of mechanical work

          If it's a *lot* of mechanical work, then it seems like there's a problem.

          > - this can't be TDD very well - we use dbunit, so we need some data
          > first to create baseline XML

          Hmmm... I've used dbUnit to TDD db access quite a bit in the past. I've
          just pushed in the data I needed for the test.

          > - basically every time, when one person is just watching and can't
          > add value for some time

          This should never be the case. It's an indicator that the pairing isn't
          being performed effectively.

          A couple things I've learned about pairing:
          1. It's really good to verbalize whatever you're doing. Your pair
          can't read your mind, and reverse-engineering what you type is too slow
          and leaves them behind.
          2. Pairing is a lot like improv theatre. You want to increase the
          possibilities, not control the story.

          - George

          --
          ----------------------------------------------------------------------
          * George Dinwiddie * http://blog.gdinwiddie.com
          Software Development http://www.idiacomputing.com
          Consultant and Coach http://www.agilemaryland.org
          ----------------------------------------------------------------------
        • Jeff Anderson
          Last project I pair programmed on, I found that pairing was useful for about 75% of the time, sure mechanical code should be automated, but this needs to be
          Message 4 of 9 , Jul 29, 2010
          • 0 Attachment
            Last project I pair programmed on, I found that pairing was useful
            for about 75% of the time, sure mechanical code should be automated,
            but this needs to be evaluated against wether you make your sprint
            objectives or not.

            I didn't find pairing useful for:
            - data mapping for integration work
            - configuring COTS
            - running code generators to create WSDLs

            All the stuff that probably should get automated at some point but
            doesn't because of some bad excuse or other, like framework
            limitation, time pressure, or capability of team, including mine.

            But for the real knowledge work where craft matters, yes to pair
            programming, so much quicker than single developers.

            Jeff




            On 7/29/10, Adam Sroka <adam.sroka@...> wrote:
            > On Thu, Jul 29, 2010 at 2:41 PM, strazhce <infobox.oleg@...> wrote:
            >>
            >>
            >>
            >> Hi.
            >>
            >> We've been doing pair programming recently (see may previous posts). It's
            >> new for us, so we discover some interesting things.
            >>
            >> One thing is: when does it make to pair program and when it doesn't.
            >>
            >> When it does: for us clearly when there is a huge knowledge difference
            >> between two. When one needs some knowledge and the other one doesn't.
            >>
            >
            > Or when neither has the knowledge, because:
            >
            > 1) It is easier to learn when you have someone to help you.
            > 2) It is easier to reinforce new habits (Like when you are just
            > starting to write the test first) if someone is there to remind you.
            > 3) I don't have the citations of the top of my head, but studies have
            > shown that we solve problems more effectively when we talk through
            > them with someone else.
            >
            >> When it doesn't:
            >> - programming database access - it seems this task is so mechanical, that
            >> it is not worth to pair program (we use stored procedures only for DB
            >> access - customer policy, so writing SP + Spring SP wrapper for it is a
            >> lot of mechanical work
            >> - this can't be TDD very well - we use dbunit, so we need some data first
            >> to create baseline XML
            >> - basically every time, when one person is just watching and can't add
            >> value for some time
            >>
            >
            > This is true. Mechanical tasks are not ideal for pair programming. Of
            > course, mechanical tasks are not the best use of a single programmer's
            > time either. Perhaps you should consider automating them? And perhaps
            > a pair could figure out how to write that automation more
            > quickly/effectively than an individual?
            >
            > There are also times when you don't know what you are doing and need a
            > minute to read the docs. This is best done individually, but it might
            > be worthwhile to keep such activities brief and get back together to
            > discuss what you have learned sooner than later.
            >
            > One more thing: never, ever tell people that they have to pair all the
            > time. Imposing practices is generally problematic, but this is one of
            > the worst ones to impose, because it all but guarantees that one
            > person will do the work while the other daydreams.
            >

            --
            Sent from my mobile device

            Jeff Anderson

            http://agileconsulting.blogspot.com/
          • JeffGrigg
            ... I generally find that most tasks that do not work out well with pairing shouldn t be done by a person at all: They should be automated. ... I think that
            Message 5 of 9 , Jul 29, 2010
            • 0 Attachment
              --- Adam Sroka <adam.sroka@...> wrote:
              > [...], mechanical tasks are not the best use of a single
              > programmer's time either.

              I generally find that most tasks that do not work out well with pairing shouldn't be done by a person at all: They should be automated.

              > There are also times when you don't know what you are doing
              > and need a minute to read the docs. This is best done
              > individually, but it might be worthwhile to keep such
              > activities brief and get back together to discuss what you
              > have learned sooner than later.

              I think that there are some things that I do better alone than with a pair. But it's not that much, and it's very hard to tell where the line is. So I gain more by pairing on everything: Inefficiencies caused by pairing when it doesn't work out so well are far outweighed by the benefits of pairing when I wouldn't otherwise have thought to ask for it. That is, the costs of working alone when pairing would really would have been better can be very high.

              It's kind of line "quality time" with your kids: You never know when it's going to happen, so it's good to be ready when it does. Likewise, you don't know when a pair partner could have had an insight that would have saved you lots of time. So it's better to have the help, even if sometimes you don't need it.


              > One more thing: never, ever tell people that they have to
              > pair all the time.

              I've done that. It's worked well for me. (But it does depend on the environment and circumstances.)

              > [...] all but guarantees that one person will do the work
              > while the other daydreams.

              Yea; well, I fired him. Problem solved.

              (If pairing had been the only problem, we'd have found him other work to do. Work that didn't require pairing.)
            • Adam Sroka
              ... If the team wants to pair, I think that is great. For some reason pairing is the one thing that some developers are violently opposed to but can t (or
              Message 6 of 9 , Jul 29, 2010
              • 0 Attachment
                On Thu, Jul 29, 2010 at 6:35 PM, JeffGrigg <jeffreytoddgrigg@...> wrote:
                >
                >
                > > One more thing: never, ever tell people that they have to
                > > pair all the time.
                >
                > I've done that. It's worked well for me. (But it does depend on the environment and circumstances.)
                >

                If the team wants to pair, I think that is great. For some reason
                pairing is the one thing that some developers are violently opposed to
                but can't (or won't) argue rationally against. I find suggesting to
                someone who doesn't pair that they start is a recipe for resistance
                (And the passive aggressive kind that is hard to confront.)

                I have gotten much better mileage from simply introducing WIP limits
                and suggesting that the team get stuff done so that they can get on to
                other stuff. This forces them to start thinking about how they can
                help each other, which means they have to talk, which means that pair
                programming suddenly becomes a good idea.

                This is mostly an issue of coaching style. YMMV.
              • D.AndrĂ© Dhondt
                ... When we need to do research, we break up for an agreed upon time... that way everyone can read at their own speed, and then come back to say what they
                Message 7 of 9 , Jul 30, 2010
                • 0 Attachment
                  On Thu, Jul 29, 2010 at 11:41 PM, strazhce <infobox.oleg@...> wrote:

                  > 1. when it does and doesn't make sense to pair?
                  >

                  When we need to do research, we break up for an agreed upon time... that way
                  everyone can read at their own speed, and then come back to say what they
                  learned.

                  Sometimes it's nice to do a spike solo, too. Other times it works better as
                  a pair.

                  --
                  D. André Dhondt
                  mobile: 011 33 671 034 984
                  twitter: adhondt http://dhondtsayitsagile.blogspot.com/

                  Support low-cost conferences -- http://AgileTour.org/
                  If you're in the area, join Agile Philly http://www.AgilePhilly.com


                  [Non-text portions of this message have been removed]
                • daswartz@prodigy
                  Hello Adam, ... And cultural environment. It is very difficult to inculcate pairing in an environment where individual heros are rewarded highly and team
                  Message 8 of 9 , Aug 3, 2010
                  • 0 Attachment
                    Hello Adam,

                    Thursday, July 29, 2010, 9:09:59 PM, you wrote:

                    > On Thu, Jul 29, 2010 at 6:35 PM, JeffGrigg
                    > <jeffreytoddgrigg@...> wrote:
                    >>
                    >>
                    >> > One more thing: never, ever tell people that they have to
                    >> > pair all the time.
                    >>
                    >> I've done that. It's worked well for me. (But it does depend on the environment and circumstances.)
                    >>

                    > If the team wants to pair, I think that is great. For some reason
                    > pairing is the one thing that some developers are violently opposed to
                    > but can't (or won't) argue rationally against. I find suggesting to
                    > someone who doesn't pair that they start is a recipe for resistance
                    > (And the passive aggressive kind that is hard to confront.)

                    > I have gotten much better mileage from simply introducing WIP limits
                    > and suggesting that the team get stuff done so that they can get on to
                    > other stuff. This forces them to start thinking about how they can
                    > help each other, which means they have to talk, which means that pair
                    > programming suddenly becomes a good idea.

                    > This is mostly an issue of coaching style. YMMV.

                    And cultural environment. It is very difficult to inculcate pairing in
                    an environment where individual heros are rewarded highly and team
                    players are ignored, or in an environment where asking for help is
                    considered an admission of weakness or lower skill.


                    --
                    Doug Swartz
                  • Adam Sroka
                    ... True, but if that were the case pairing wouldn t be my first concern (Nor second.)
                    Message 9 of 9 , Aug 3, 2010
                    • 0 Attachment
                      On Tue, Aug 3, 2010 at 9:05 AM, daswartz@prodigy <daswartz@...> wrote:
                      >
                      >
                      >
                      > Hello Adam,
                      >
                      > Thursday, July 29, 2010, 9:09:59 PM, you wrote:
                      >
                      > > On Thu, Jul 29, 2010 at 6:35 PM, JeffGrigg
                      > > <jeffreytoddgrigg@...> wrote:
                      > >>
                      > >>
                      > >> > One more thing: never, ever tell people that they have to
                      > >> > pair all the time.
                      > >>
                      > >> I've done that. It's worked well for me. (But it does depend on the environment and circumstances.)
                      > >>
                      >
                      > > If the team wants to pair, I think that is great. For some reason
                      > > pairing is the one thing that some developers are violently opposed to
                      > > but can't (or won't) argue rationally against. I find suggesting to
                      > > someone who doesn't pair that they start is a recipe for resistance
                      > > (And the passive aggressive kind that is hard to confront.)
                      >
                      > > I have gotten much better mileage from simply introducing WIP limits
                      > > and suggesting that the team get stuff done so that they can get on to
                      > > other stuff. This forces them to start thinking about how they can
                      > > help each other, which means they have to talk, which means that pair
                      > > programming suddenly becomes a good idea.
                      >
                      > > This is mostly an issue of coaching style. YMMV.
                      >
                      > And cultural environment. It is very difficult to inculcate pairing in
                      > an environment where individual heros are rewarded highly and team
                      > players are ignored, or in an environment where asking for help is
                      > considered an admission of weakness or lower skill.
                      >

                      True, but if that were the case pairing wouldn't be my first concern
                      (Nor second.)
                    Your message has been successfully submitted and would be delivered to recipients shortly.