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

Pair Programming Measures

Expand Messages
  • MarvinToll.com
    Has the dust ever settled on this topic? My understanding is that there is some consensus that quantitative metrics in this area are not all that useful...
    Message 1 of 12 , Oct 8, 2012
    • 0 Attachment
      Has the dust ever settled on this topic? My understanding is that there is some consensus that quantitative metrics in this area are not all that useful... however, there may be more validity to qualitative measures.

      _Marvin
    • Rob Myers
      The only quantitative metrics I recall reading about were done by Laurie Williams, and were taken in an academic setting. She found that the defect rates were
      Message 2 of 12 , Oct 9, 2012
      • 0 Attachment
        The only quantitative metrics I recall reading about were done by Laurie Williams, and were taken in an academic setting.

        She found that the defect rates were much lower, but the development time was a little higher. It was shown to be a net win.

        In my experience, paired development time is not slower, but faster, for a whole list of qualitative, behavioral reasons. When it comes to knowledge work (surgery, flying an airliner, writing production-ready code), on average, two people will complete two tasks faster together than separately.

        I'd love it if someone could fund more industry research. I have plenty of hypotheses that need testing. ;-)


        --- In extremeprogramming@yahoogroups.com, "MarvinToll.com" <MarvinToll@...> wrote:
        >
        > Has the dust ever settled on this topic? My understanding is that there is some consensus that quantitative metrics in this area are not all that useful... however, there may be more validity to qualitative measures.
        >
        > _Marvin
        >
      • Steven Gordon
        Rob, I believe Marvin had in mind metrics that could be used to manage teams without having to directly interact with them (particularly outsourced teams)
        Message 3 of 12 , Oct 9, 2012
        • 0 Attachment
          Rob,

          I believe Marvin had in mind metrics that could be used to manage teams
          without having to directly interact with them (particularly outsourced
          teams) rather than metrics to be used to make the case for doing pairing.

          But, since you brought the topic up and there was a time several years ago
          that I thought quite a bit about it, I will brain dump it here:

          My intuition is that if you took a statistically significant number of
          student programmers and compare pair programming performance to individual
          programming performance for the amount of time the students were willing to
          participate for free, that you would indeed find much lower defect rates
          and somewhat longer development time. The issue is that student
          programmers are quite a bit different from professionals, programming tasks
          that take students just a few hours are quite a bit different than
          realistic programming tasks, and the amount of time it takes to get good at
          pairing is too long for a free or low cost study.

          If one could afford to do a study of a statistically significant number of
          professional programmers over a long enough period of time to get good at
          pair programming and do non-trivial programming, I would expect to see
          shorter development time, not quite as much reduction in defects, and also
          a significant reduction in "technical debt" (which is probably the most
          important long-term effect).

          The most affordable way would be to compare individual programming before
          with pairing afterwards in a company transitioning. Unfortunately, there
          would be many dependent variables that would be uncontrolled (especially
          because there would likely be a lot of other changes occurring in the same
          time frame in a transitional professional environment other than just going
          from individual programming to pair programming). This would end up just
          being a case study.

          Ultimately, a study is not of that much practical value. Teams will only
          stick with pair programming if the team finds value in it regardless of any
          studies.


          On Tue, Oct 9, 2012 at 10:36 AM, Rob Myers <rob.myers@...>wrote:

          > **
          >
          >
          > The only quantitative metrics I recall reading about were done by Laurie
          > Williams, and were taken in an academic setting.
          >
          > She found that the defect rates were much lower, but the development time
          > was a little higher. It was shown to be a net win.
          >
          > In my experience, paired development time is not slower, but faster, for a
          > whole list of qualitative, behavioral reasons. When it comes to knowledge
          > work (surgery, flying an airliner, writing production-ready code), on
          > average, two people will complete two tasks faster together than separately.
          >
          > I'd love it if someone could fund more industry research. I have plenty of
          > hypotheses that need testing. ;-)
          >
          > --- In extremeprogramming@yahoogroups.com, "MarvinToll.com" <MarvinToll@...>
          > wrote:
          > >
          > > Has the dust ever settled on this topic? My understanding is that there
          > is some consensus that quantitative metrics in this area are not all that
          > useful... however, there may be more validity to qualitative measures.
          > >
          > > _Marvin
          > >
          >
          >
          >


          [Non-text portions of this message have been removed]
        • John Goodsen
          ... good luck with that little fantasy. -- John Goodsen RADSoft / Better Software Faster jgoodsen@radsoft.com Lean/Kanban/XP/Scrum
          Message 4 of 12 , Oct 9, 2012
          • 0 Attachment
            On Tue, Oct 9, 2012 at 7:40 PM, Steven Gordon <sgordonphd@...> wrote:

            > Rob,
            >
            > I believe Marvin had in mind metrics that could be used to manage teams
            > without having to directly interact with them (particularly outsourced
            > teams) rather than metrics to be used to make the case for doing pairing.
            >

            good luck with that little fantasy.

            --
            John Goodsen RADSoft / Better Software Faster
            jgoodsen@... Lean/Kanban/XP/Scrum Coaching and Training
            http://www.radsoft.com Enterprise Ruby, Java and Scala Solutions


            [Non-text portions of this message have been removed]
          • MarvinToll.com
            Thank you Rob... my impression was that the quantitive metrics available are not establishing a strong case for pairing. I remain hopeful that some day we
            Message 5 of 12 , Oct 11, 2012
            • 0 Attachment
              Thank you Rob... my impression was that the quantitive metrics available are not establishing a strong case for pairing.

              I remain hopeful that some day we might have qualitative measures useful for making the case.

              _Marvin

              --- In extremeprogramming@yahoogroups.com, "Rob Myers" <rob.myers@...> wrote:
              >
              > The only quantitative metrics I recall reading about were done by Laurie Williams, and were taken in an academic setting.
              >
              > She found that the defect rates were much lower, but the development time was a little higher. It was shown to be a net win.
              >
              > In my experience, paired development time is not slower, but faster, for a whole list of qualitative, behavioral reasons. When it comes to knowledge work (surgery, flying an airliner, writing production-ready code), on average, two people will complete two tasks faster together than separately.
              >
              > I'd love it if someone could fund more industry research. I have plenty of hypotheses that need testing. ;-)
              >
              >
              > --- In extremeprogramming@yahoogroups.com, "MarvinToll.com" <MarvinToll@> wrote:
              > >
              > > Has the dust ever settled on this topic? My understanding is that there is some consensus that quantitative metrics in this area are not all that useful... however, there may be more validity to qualitative measures.
              > >
              > > _Marvin
              > >
              >
            • Curtis Cooley
              ... team velocity as it is, so how could you use it to measure pair programming efficiency. All the issues we have with estimation and planning will still be
              Message 6 of 12 , Oct 11, 2012
              • 0 Attachment
                On Thu, Oct 11, 2012 at 7:05 AM, MarvinToll.com <MarvinToll@...>wrote:

                > **
                >
                >
                > Thank you Rob... my impression was that the quantitive metrics available
                > are not establishing a strong case for pairing.
                >
                > I remain hopeful that some day we might have qualitative measures useful
                > for making the case.
                >
                > What qualitative metrics would you use? We already have issues measuring
                team velocity as it is, so how could you use it to measure pair programming
                efficiency. All the issues we have with estimation and planning will still
                be there.

                I agree with Steve, it is unlikely to happen.

                "Build projects around motivated individuals. Give them the environment and
                support they need and TRUST them to get the job done."

                If your team of motivated individuals believes pair programming will help
                them get the job done, you should trust them and not make them prove it's
                more effective.
                --
                --------------------------------------
                Curtis Cooley
                curtis@...


                [Non-text portions of this message have been removed]
              • Steven Gordon
                Agile teams should try pairing because they have a problem with quality and/or knowledge silos and believe it may help them address their problem. And then
                Message 7 of 12 , Oct 11, 2012
                • 0 Attachment
                  Agile teams should try pairing because they have a problem with quality
                  and/or knowledge silos and believe it may help them address their problem.
                  And then they try it and retrospect on it to see if it helps and if not
                  whether they should try to do it better or abandon the idea. This goes for
                  other practices as well.

                  Doing something because somebody else "proved" that it work for them is
                  backwards. Doing something because some manager tells them to do it
                  because somebody else "proved" that it work for them is double backwards.

                  Metrics are so context-sensitive that they just do not translate from one
                  situation to another. They are useful for seeing if a specific team is
                  getting better over time, but they are not good for comparing teams or
                  deciding if a practice works well in general.

                  The expense of taking the context-sensitivity out of metrics is only
                  warranted for things like drugs and medical procedures, not software
                  development.

                  Agile opens the door for each team to take responsibility of using their
                  own metrics to improve their own process - promote that. Providing
                  guidelines and feedback for how to do that is conducive to agility. In my
                  opinion, attempting to do it generally it for all teams is prohibitively
                  expensive to do validly and inhibits the long term agility of individual
                  teams.

                  Steven Gordon

                  On Thu, Oct 11, 2012 at 7:05 AM, MarvinToll.com <MarvinToll@...>wrote:

                  > **
                  >
                  >
                  > Thank you Rob... my impression was that the quantitive metrics available
                  > are not establishing a strong case for pairing.
                  >
                  > I remain hopeful that some day we might have qualitative measures useful
                  > for making the case.
                  >
                  > _Marvin
                  >
                  >
                  > --- In extremeprogramming@yahoogroups.com, "Rob Myers" <rob.myers@...>
                  > wrote:
                  > >
                  > > The only quantitative metrics I recall reading about were done by Laurie
                  > Williams, and were taken in an academic setting.
                  > >
                  > > She found that the defect rates were much lower, but the development
                  > time was a little higher. It was shown to be a net win.
                  > >
                  > > In my experience, paired development time is not slower, but faster, for
                  > a whole list of qualitative, behavioral reasons. When it comes to knowledge
                  > work (surgery, flying an airliner, writing production-ready code), on
                  > average, two people will complete two tasks faster together than separately.
                  > >
                  > > I'd love it if someone could fund more industry research. I have plenty
                  > of hypotheses that need testing. ;-)
                  > >
                  > >
                  > > --- In extremeprogramming@yahoogroups.com, "MarvinToll.com" <MarvinToll@>
                  > wrote:
                  > > >
                  > > > Has the dust ever settled on this topic? My understanding is that
                  > there is some consensus that quantitative metrics in this area are not all
                  > that useful... however, there may be more validity to qualitative measures.
                  > > >
                  > > > _Marvin
                  > > >
                  > >
                  >
                  >
                  >


                  [Non-text portions of this message have been removed]
                • Jeff Langr
                  Few people ever quantify things like the true cost of a defect. Here s why I pair: http://pragprog.com/magazines/2011-07/pair-programming-benefits Jeff L.
                  Message 8 of 12 , Oct 11, 2012
                  • 0 Attachment
                    Few people ever quantify things like the true cost of a defect.

                    Here's why I pair:
                    http://pragprog.com/magazines/2011-07/pair-programming-benefits

                    Jeff L.

                    Langr Software Solutions
                    http://langrsoft.com
                    http://agileinaflash.com - Agile in a Flash: A top 20 agile book!
                    (http://www.noop.nl/2010/08/top-100-agile-books.html)


                    On Thu, Oct 11, 2012 at 7:05 AM, MarvinToll.com <MarvinToll@...> wrote:
                    > Thank you Rob... my impression was that the quantitive metrics available are not establishing a strong case for pairing.
                    >
                    > I remain hopeful that some day we might have qualitative measures useful for making the case.
                    >
                    > _Marvin
                    >
                    > --- In extremeprogramming@yahoogroups.com, "Rob Myers" <rob.myers@...> wrote:
                    >>
                    >> The only quantitative metrics I recall reading about were done by Laurie Williams, and were taken in an academic setting.
                    >>
                    >> She found that the defect rates were much lower, but the development time was a little higher. It was shown to be a net win.
                    >>
                    >> In my experience, paired development time is not slower, but faster, for a whole list of qualitative, behavioral reasons. When it comes to knowledge work (surgery, flying an airliner, writing production-ready code), on average, two people will complete two tasks faster together than separately.
                    >>
                    >> I'd love it if someone could fund more industry research. I have plenty of hypotheses that need testing. ;-)
                    >>
                    >>
                    >> --- In extremeprogramming@yahoogroups.com, "MarvinToll.com" <MarvinToll@> wrote:
                    >> >
                    >> > Has the dust ever settled on this topic? My understanding is that there is some consensus that quantitative metrics in this area are not all that useful... however, there may be more validity to qualitative measures.
                    >> >
                    >> > _Marvin
                    >> >
                    >>
                    >
                    >
                    >
                    >
                    > ------------------------------------
                    >
                    > To Post a message, send it to: extremeprogramming@...
                    >
                    > To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe@...
                    >
                    > ad-free courtesy of objectmentor.comYahoo! Groups Links
                    >
                    >
                    >
                  • Francis Fish
                    ... +1 - the very important point there, which is often missed, is improving your own and other s capability. If you re relatively new and there are idiomatic
                    Message 9 of 12 , Oct 12, 2012
                    • 0 Attachment
                      On Fri, Oct 12, 2012 at 4:37 AM, Jeff Langr <jeff@...> wrote:

                      > **
                      >
                      >
                      > Few people ever quantify things like the true cost of a defect.
                      >
                      > Here's why I pair:
                      > http://pragprog.com/magazines/2011-07/pair-programming-benefits
                      >
                      > Jeff L.
                      >
                      >
                      +1 - the very important point there, which is often missed, is improving
                      your own and other's capability. If you're relatively new and there are
                      idiomatic ways of doing things that you don't know then you need to pair
                      with someone who does. When you question the idioms you will be helping the
                      more experienced person understand them better too, and maybe even change
                      them if they aren't quite right.

                      I did a talk on YAGNI a while back and one of the things I said was we
                      often go off down rabbit holes and start working on things that don't work
                      or are a bad choice. Pairing helps stop this in its tracks, and it also
                      stops yak shaving. I have abso no idea how you would measure this but I'd
                      bet that this is why it seems much more productive: the code that's written
                      is solving the right problem because it needs two minds agreeing to justify
                      its existence. In terms of lines per day (or some other useless metric)
                      there may well be less, but in terms of *relevant* lines per day quite
                      likely far more. I suppose a metric around defects (or more likely uncaught
                      defects that testers find) might give some indirect indication.

                      If you go down the metrics route, any kind of metric that at least gives
                      you an idea is better than none at all. But you also need to understand
                      statistics and the ineluctable fact that measurements falling within three
                      standard deviations of the mean actually indicate there is little room for
                      improvement without changing the "system" as a whole. I'd suggest people
                      track down a copy of "4 days with Dr Deming" if they want this explained in
                      more detail. For example, Deming ridiculed the idea of performance reviews
                      - if 95% of the variability of anyone's performance comes from the tools
                      and training they've been given and the overall system they're forced to
                      work with, marking them up or down is really unfair. <sarcasm> For some
                      reason the command & control management types don't like this. Probably
                      because the overall system is their responsibility and improving it would
                      mean they'd have to do something other than bully people, like thinking and
                      some real work. </sarcasm>


                      [Non-text portions of this message have been removed]
                    • Daniel Wildt
                      In my experience, pairing must come together with a purpose. We found that the team is learning much more when doing pairing sessions. We were able to improve
                      Message 10 of 12 , Oct 12, 2012
                      • 0 Attachment
                        In my experience, pairing must come together with a purpose. We found that
                        the team is learning much more when doing pairing sessions.

                        We were able to improve much faster our business knowledge doing pairing
                        sessions. Same thing happened with technical knowledge creation where
                        people with more experience paired more often with people with less
                        experience.

                        The "ramp up" process had also a big benefit from pairing. Every new person
                        on the team is asked to try to pair 100% of the time when touching
                        production code. Which they start doing on day 1.

                        Pairing was also very important integrating business analysts and
                        developers.

                        And everything started with Coding Dojos. Where developers could practice
                        programming and also pairing, test automation, respect, they learn that
                        they can learn and teach other people. They learn how to create knowledge
                        while delivering a feature.

                        -- Daniel Wildt - @dwildt <http://twitter.com/dwildt>


                        On Thu, Oct 11, 2012 at 3:11 PM, Steven Gordon <sgordonphd@...> wrote:

                        > Agile teams should try pairing because they have a problem with quality
                        > and/or knowledge silos and believe it may help them address their problem.
                        > And then they try it and retrospect on it to see if it helps and if not
                        > whether they should try to do it better or abandon the idea. This goes for
                        > other practices as well.
                        >
                        > Doing something because somebody else "proved" that it work for them is
                        > backwards. Doing something because some manager tells them to do it
                        > because somebody else "proved" that it work for them is double backwards.
                        >
                        > Metrics are so context-sensitive that they just do not translate from one
                        > situation to another. They are useful for seeing if a specific team is
                        > getting better over time, but they are not good for comparing teams or
                        > deciding if a practice works well in general.
                        >
                        > The expense of taking the context-sensitivity out of metrics is only
                        > warranted for things like drugs and medical procedures, not software
                        > development.
                        >
                        > Agile opens the door for each team to take responsibility of using their
                        > own metrics to improve their own process - promote that. Providing
                        > guidelines and feedback for how to do that is conducive to agility. In my
                        > opinion, attempting to do it generally it for all teams is prohibitively
                        > expensive to do validly and inhibits the long term agility of individual
                        > teams.
                        >
                        > Steven Gordon
                        >
                        > On Thu, Oct 11, 2012 at 7:05 AM, MarvinToll.com <MarvinToll@...
                        > >wrote:
                        >
                        > > **
                        > >
                        > >
                        > > Thank you Rob... my impression was that the quantitive metrics available
                        > > are not establishing a strong case for pairing.
                        > >
                        > > I remain hopeful that some day we might have qualitative measures useful
                        > > for making the case.
                        > >
                        > > _Marvin
                        > >
                        > >
                        > > --- In extremeprogramming@yahoogroups.com, "Rob Myers" <rob.myers@...>
                        > > wrote:
                        > > >
                        > > > The only quantitative metrics I recall reading about were done by
                        > Laurie
                        > > Williams, and were taken in an academic setting.
                        > > >
                        > > > She found that the defect rates were much lower, but the development
                        > > time was a little higher. It was shown to be a net win.
                        > > >
                        > > > In my experience, paired development time is not slower, but faster,
                        > for
                        > > a whole list of qualitative, behavioral reasons. When it comes to
                        > knowledge
                        > > work (surgery, flying an airliner, writing production-ready code), on
                        > > average, two people will complete two tasks faster together than
                        > separately.
                        > > >
                        > > > I'd love it if someone could fund more industry research. I have plenty
                        > > of hypotheses that need testing. ;-)
                        > > >
                        > > >
                        > > > --- In extremeprogramming@yahoogroups.com, "MarvinToll.com"
                        > <MarvinToll@>
                        > > wrote:
                        > > > >
                        > > > > Has the dust ever settled on this topic? My understanding is that
                        > > there is some consensus that quantitative metrics in this area are not
                        > all
                        > > that useful... however, there may be more validity to qualitative
                        > measures.
                        > > > >
                        > > > > _Marvin
                        > > > >
                        > > >
                        > >
                        > >
                        > >
                        >
                        >
                        > [Non-text portions of this message have been removed]
                        >
                        >
                        >
                        > ------------------------------------
                        >
                        > To Post a message, send it to: extremeprogramming@...
                        >
                        > To Unsubscribe, send a blank message to:
                        > extremeprogramming-unsubscribe@...
                        >
                        > ad-free courtesy of objectmentor.comYahoo! Groups Links
                        >
                        >
                        >
                        >


                        [Non-text portions of this message have been removed]
                      • Ian Mitchell
                        My experience has led me to the following: 1. The biggest source of errors is not understanding the problem before inventing the solution. Not understanding
                        Message 11 of 12 , Oct 13, 2012
                        • 0 Attachment
                          My experience has led me to the following:
                          1. The biggest source of errors is not understanding the problem before
                          inventing the solution. Not understanding includes not thinking deeply
                          enough and not spotting ambiguities. Two people discussing a problem often
                          help clarify it and ensure that they understand its true width. Defects
                          like this survive into production and hence are the most expensive.
                          2. Always enforce pre- and post- assertion approaches.
                          3. Then write the test harness so the criteria for a correct solution is
                          agreed before much code is written.
                          4. Another major factor is that if we make a typo we often do not see it
                          [if it is compilable] because we see what we knew we wrote whereas someone
                          else immediately sees that that is not what they would have written.
                          5. Personality impacts pair programming - sometimes two people work
                          effectively together but sometimes one person effectively just watches the
                          other person - particularly if one is experienced and the other a newbie.
                          6. Also if the code follows a familiar pattern the second member of the
                          pair cannot contribute much.

                          On 13 October 2012 11:47, Daniel Wildt <dwildt@...> wrote:

                          > **
                          >
                          >
                          > In my experience, pairing must come together with a purpose. We found that
                          > the team is learning much more when doing pairing sessions.
                          >
                          > We were able to improve much faster our business knowledge doing pairing
                          > sessions. Same thing happened with technical knowledge creation where
                          > people with more experience paired more often with people with less
                          > experience.
                          >
                          > The "ramp up" process had also a big benefit from pairing. Every new person
                          > on the team is asked to try to pair 100% of the time when touching
                          > production code. Which they start doing on day 1.
                          >
                          > Pairing was also very important integrating business analysts and
                          > developers.
                          >
                          > And everything started with Coding Dojos. Where developers could practice
                          > programming and also pairing, test automation, respect, they learn that
                          > they can learn and teach other people. They learn how to create knowledge
                          > while delivering a feature.
                          >
                          > -- Daniel Wildt - @dwildt <http://twitter.com/dwildt>
                          >
                          >
                          > On Thu, Oct 11, 2012 at 3:11 PM, Steven Gordon <sgordonphd@...>
                          > wrote:
                          >
                          > > Agile teams should try pairing because they have a problem with quality
                          > > and/or knowledge silos and believe it may help them address their
                          > problem.
                          > > And then they try it and retrospect on it to see if it helps and if not
                          > > whether they should try to do it better or abandon the idea. This goes
                          > for
                          > > other practices as well.
                          > >
                          > > Doing something because somebody else "proved" that it work for them is
                          > > backwards. Doing something because some manager tells them to do it
                          > > because somebody else "proved" that it work for them is double backwards.
                          > >
                          > > Metrics are so context-sensitive that they just do not translate from one
                          > > situation to another. They are useful for seeing if a specific team is
                          > > getting better over time, but they are not good for comparing teams or
                          > > deciding if a practice works well in general.
                          > >
                          > > The expense of taking the context-sensitivity out of metrics is only
                          > > warranted for things like drugs and medical procedures, not software
                          > > development.
                          > >
                          > > Agile opens the door for each team to take responsibility of using their
                          > > own metrics to improve their own process - promote that. Providing
                          > > guidelines and feedback for how to do that is conducive to agility. In my
                          > > opinion, attempting to do it generally it for all teams is prohibitively
                          > > expensive to do validly and inhibits the long term agility of individual
                          > > teams.
                          > >
                          > > Steven Gordon
                          > >
                          > > On Thu, Oct 11, 2012 at 7:05 AM, MarvinToll.com <MarvinToll@...
                          > > >wrote:
                          > >
                          > > > **
                          > > >
                          > > >
                          > > > Thank you Rob... my impression was that the quantitive metrics
                          > available
                          > > > are not establishing a strong case for pairing.
                          > > >
                          > > > I remain hopeful that some day we might have qualitative measures
                          > useful
                          > > > for making the case.
                          > > >
                          > > > _Marvin
                          > > >
                          > > >
                          > > > --- In extremeprogramming@yahoogroups.com, "Rob Myers" <rob.myers@...>
                          > > > wrote:
                          > > > >
                          > > > > The only quantitative metrics I recall reading about were done by
                          > > Laurie
                          > > > Williams, and were taken in an academic setting.
                          > > > >
                          > > > > She found that the defect rates were much lower, but the development
                          > > > time was a little higher. It was shown to be a net win.
                          > > > >
                          > > > > In my experience, paired development time is not slower, but faster,
                          > > for
                          > > > a whole list of qualitative, behavioral reasons. When it comes to
                          > > knowledge
                          > > > work (surgery, flying an airliner, writing production-ready code), on
                          > > > average, two people will complete two tasks faster together than
                          > > separately.
                          > > > >
                          > > > > I'd love it if someone could fund more industry research. I have
                          > plenty
                          > > > of hypotheses that need testing. ;-)
                          > > > >
                          > > > >
                          > > > > --- In extremeprogramming@yahoogroups.com, "MarvinToll.com"
                          > > <MarvinToll@>
                          > > > wrote:
                          > > > > >
                          > > > > > Has the dust ever settled on this topic? My understanding is that
                          > > > there is some consensus that quantitative metrics in this area are not
                          > > all
                          > > > that useful... however, there may be more validity to qualitative
                          > > measures.
                          > > > > >
                          > > > > > _Marvin
                          > > > > >
                          > > > >
                          > > >
                          > > >
                          > > >
                          > >
                          > >
                          > > [Non-text portions of this message have been removed]
                          > >
                          > >
                          > >
                          > > ------------------------------------
                          > >
                          > > To Post a message, send it to: extremeprogramming@...
                          > >
                          > > To Unsubscribe, send a blank message to:
                          > > extremeprogramming-unsubscribe@...
                          > >
                          > > ad-free courtesy of objectmentor.comYahoo! Groups Links
                          > >
                          > >
                          > >
                          > >
                          >
                          > [Non-text portions of this message have been removed]
                          >
                          >
                          >



                          --
                          Regards
                          Ian Mitchell, FIITP ITCP
                          ICT and Management Consultant
                          2/40 Sylvia Road
                          St Heliers
                          Auckland, New Zealand
                          0064 9 5851580
                          http://www.Mitchell.co.nz
                          http://www.AboutIT.co.nz
                          http://www.SoftwareAsAService.co.nz


                          [Non-text portions of this message have been removed]
                        • Tim Ottinger
                          ... I don t quite understand the question. Are you asking about studies that suggest pairing is more effective? Or whether it s good to measure pair
                          Message 12 of 12 , Oct 15, 2012
                          • 0 Attachment
                            > Has the dust ever settled on this topic?  My understanding is that there is some 
                            > consensus that quantitative metrics in this area are not all that useful... 
                            > however, there may be more validity to qualitative measures.


                            I don't quite understand the question.

                            Are you asking about studies that suggest pairing is more effective?
                            Or whether it's good to measure pair programming as it happens? 



                             
                            Tim Ottinger <tottinge@...>
                            http://industriallogic.com/
                            http://agileotter.blogspot.com/
                          Your message has been successfully submitted and would be delivered to recipients shortly.