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

Re: [XP] Overview of software engineering methods makes some controversial conclusions

Expand Messages
  • Charlie Poole
    I love it! ... [Non-text portions of this message have been removed]
    Message 1 of 22 , Mar 26, 2013
    • 0 Attachment
      I love it!


      On Tue, Mar 26, 2013 at 8:46 AM, Phlip <phlip2005@...> wrote:

      > **
      >
      >
      > > I'll be a little selective on his findings, but I was a bit surprised
      > that
      > > for XP, he considers "that pair programming is an expensive mistake."
      >
      > Of course it is. My code is awesome, but then I always get stuck with
      > someone who thinks it sucks. Then we have to waste time appeasing
      > them. Sheesh...
      >
      > --
      > Phlip
      > http://c2.com/cgi/wiki?ZeekLand
      >
      >
      >


      [Non-text portions of this message have been removed]
    • Charlie Poole
      Hi Allen, It s Capers Jones... what did you expect? Most agile approaches, and XP in particular since that s where we are talking, emphasize speed, quality,
      Message 2 of 22 , Mar 26, 2013
      • 0 Attachment
        Hi Allen,

        It's Capers Jones... what did you expect?

        Most agile approaches, and XP in particular since that's where we are
        talking, emphasize speed, quality, correctness and
        developing-the-right-application. If Jones only sees the emphasis on speed,
        then he misses the point.

        Regarding pair programming, nobody who can define it as "letting two people
        take turns programming while one watched" should even be paid attention to.
        That approach probably is twice as costly and achieves nothing, but it's
        not pair programming. I recommend only paying attention when people write
        about something they actually understand.

        Charlie


        On Tue, Mar 26, 2013 at 5:51 AM, Allen Higgins <allen.higgins@...>wrote:

        > **
        >
        >
        > From Info Q. Casper Jones has produced an assessment of 10 selected 'most
        > capable' methodologies.
        >
        > http://www.infoq.com/articles/evaluating-agile-software-methodologies
        >
        > I'll be a little selective on his findings, but I was a bit surprised that
        > for XP, he considers "that pair programming is an expensive mistake."
        >
        > He concludes that methodologies give you what you want, i.e.
        > By considering that the Agile family and methods emphasize speed (not
        > feedback?) that they "have achieved their goal, and they are fairly quick."
        >
        > And that methods that "emphasize quality such as TSP, RUP, and CMMI 5 have
        > also achieved their goals, and deliver very few defects."
        >
        > But that "no single method appears to be a universal panacea that can be
        > successful on every size and kind of software application."
        >
        > Do you think the study misses the point by treating these varying
        > approaches as all of a piece, i.e. that they are comparable software
        > engineering methodologies with apparently equivalent touch points?
        >
        > And finally, is pair programming an expensive mistake? I think not but then
        > I'm enamored of 'idea' pair programming as on-going punctuated peer review
        > and/or buddy/desk-checks of design and code before committing changes. I
        > certainly don't adhere to pairing as a permanent condition, i.e. always
        > pairing all the time.
        >
        > Allen
        >
        > [Non-text portions of this message have been removed]
        >
        >
        >


        [Non-text portions of this message have been removed]
      • Allen Higgins
        Thanks Charlie, wise words. I guess I was dismayed to see it pitched in Info Q. Allen ... [Non-text portions of this message have been removed]
        Message 3 of 22 , Mar 26, 2013
        • 0 Attachment
          Thanks Charlie, wise words. I guess I was dismayed to see it pitched in
          Info Q.

          Allen


          On Tue, Mar 26, 2013 at 7:09 PM, Charlie Poole <charliepoole@...>wrote:

          > Hi Allen,
          >
          > It's Capers Jones... what did you expect?
          >
          > Most agile approaches, and XP in particular since that's where we are
          > talking, emphasize speed, quality, correctness and
          > developing-the-right-application. If Jones only sees the emphasis on speed,
          > then he misses the point.
          >
          > Regarding pair programming, nobody who can define it as "letting two people
          > take turns programming while one watched" should even be paid attention to.
          > That approach probably is twice as costly and achieves nothing, but it's
          > not pair programming. I recommend only paying attention when people write
          > about something they actually understand.
          >
          > Charlie
          >
          >
          > On Tue, Mar 26, 2013 at 5:51 AM, Allen Higgins <allen.higgins@...
          > >wrote:
          >
          > > **
          > >
          > >
          > > From Info Q. Casper Jones has produced an assessment of 10 selected 'most
          > > capable' methodologies.
          > >
          > > http://www.infoq.com/articles/evaluating-agile-software-methodologies
          > >
          > > I'll be a little selective on his findings, but I was a bit surprised
          > that
          > > for XP, he considers "that pair programming is an expensive mistake."
          > >
          > > He concludes that methodologies give you what you want, i.e.
          > > By considering that the Agile family and methods emphasize speed (not
          > > feedback?) that they "have achieved their goal, and they are fairly
          > quick."
          > >
          > > And that methods that "emphasize quality such as TSP, RUP, and CMMI 5
          > have
          > > also achieved their goals, and deliver very few defects."
          > >
          > > But that "no single method appears to be a universal panacea that can be
          > > successful on every size and kind of software application."
          > >
          > > Do you think the study misses the point by treating these varying
          > > approaches as all of a piece, i.e. that they are comparable software
          > > engineering methodologies with apparently equivalent touch points?
          > >
          > > And finally, is pair programming an expensive mistake? I think not but
          > then
          > > I'm enamored of 'idea' pair programming as on-going punctuated peer
          > review
          > > and/or buddy/desk-checks of design and code before committing changes. I
          > > certainly don't adhere to pairing as a permanent condition, i.e. always
          > > pairing all the time.
          > >
          > > Allen
          > >
          > > [Non-text portions of this message have been removed]
          > >
          > >
          > >
          >
          >
          > [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]
        • Phlip
          ... Done right, two people pair programming could take over the keyboard from each other at any time. Both know what the current goal and situation is. (And,
          Message 4 of 22 , Mar 26, 2013
          • 0 Attachment
            > Regarding pair programming, nobody who can define it as "letting two people
            > take turns programming while one watched" should even be paid attention to.
            > That approach probably is twice as costly and achieves nothing, but it's
            > not pair programming. I recommend only paying attention when people write
            > about something they actually understand.

            Done right, two people pair programming could take over the keyboard
            from each other at any time. Both know what the current goal and
            situation is. (And, as usual with XP, you can't do _that_ without TDD,
            and short releases, and continuous integration...)

            it's not just "one person watching", as if they were code-reviewing in
            real-time...
          • Tim Ottinger
            I could not find anything about this report that made sense. For instance comparing OOP v. Pair programming V. XP? WTF?  I read until the bozo bits flipped en
            Message 5 of 22 , Mar 27, 2013
            • 0 Attachment
              I could not find anything about this report that made sense.

              For instance comparing OOP v. Pair programming V. XP? WTF? 

              I read until the bozo bits flipped en masse, and dropped it. I think it's a bullshit report. I didn't have the intestinal fortitude to go study his technique of determining quality, cost, etc. It just looked like someone thrashing around. 

               
              Tim Ottinger <tottinge@...>
              http://industriallogic.com/
              http://agileotter.blogspot.com/

              [Non-text portions of this message have been removed]
            • Tim Ottinger
              He wrote: Capable individual programmers who use static analysis and participate in formal code inspections of their work produce better code for about half
              Message 6 of 22 , Mar 27, 2013
              • 0 Attachment
                He wrote:
                "Capable individual programmers who use static analysis and participate in
                formal code inspections of their work produce better code for about half
                the cost of pair programming."


                This has more problems than features.

                * Pair programmers use static analysis also. All of them I know do.

                * Pair programmers tend to use TDD. The final chapter of "Pair Programming Illuminated" is about TDD because it's the grease that makes pairing work well. That reduces errors significantly.

                * Pair programming does not double the cost. All the surveys show that pairs complete in about half the time as individuals, and that pairs tend to outperform their best members.
                I'm not sure what kind of straw man we're talking here, but I suspect that this report would be far better if the author had a decent pair working with him. 


                 
                Tim Ottinger <tottinge@...>
                http://industriallogic.com/
                http://agileotter.blogspot.com/

                [Non-text portions of this message have been removed]
              • Larry Brunelle
                Seeing as how this gent certainly has name recognition going a long way back, and that a skim of his article suggests actual gathering of data (to, at least,
                Message 7 of 22 , Mar 27, 2013
                • 0 Attachment
                  Seeing as how this gent certainly has name recognition
                  going a long way back, and that a skim of his article
                  suggests actual gathering of data (to, at least, the
                  naive executive - perhaps such people exist) - has
                  anyone like Ron, Kent, or Ward ever had opportunity
                  to engage Mr. Jones in some meaningful conversation?


                  Tim Ottinger wrote:
                  >
                  > He wrote:
                  > "Capable individual programmers who use static analysis and participate in
                  > formal code inspections of their work produce better code for about half
                  > the cost of pair programming."
                  >
                  >
                  > This has more problems than features.
                  >
                  > * Pair programmers use static analysis also. All of them I know do.
                  >
                  > * Pair programmers tend to use TDD. The final chapter of "Pair Programming Illuminated" is about TDD because it's the grease that makes pairing work well. That reduces errors significantly.
                  >
                  > * Pair programming does not double the cost. All the surveys show that pairs complete in about half the time as individuals, and that pairs tend to outperform their best members.
                  > I'm not sure what kind of straw man we're talking here, but I suspect that this report would be far better if the author had a decent pair working with him.
                  >
                  >
                  >
                  > Tim Ottinger <tottinge@...>
                  > http://industriallogic.com/
                  > http://agileotter.blogspot.com/
                • Phlip
                  Message 8 of 22 , Mar 27, 2013
                  • 0 Attachment
                    Charlie Poole wrote:

                    > I love it!

                    I had you at:

                    >> My code is awesome...
                  • Leonardo Postacchini
                    Automatic fail++; The guy is a joke. One item: agile with scrum, on the same basket: oop?!!! Agile with scrum? Seriously? Like: fruits with oranges... And
                    Message 9 of 22 , Mar 27, 2013
                    • 0 Attachment
                      Automatic fail++;

                      The guy is a joke.

                      One item: agile with scrum, on the same basket: oop?!!!

                      Agile with scrum? Seriously?

                      Like: fruits with oranges...

                      And scrum versus oop?! Just like cars vs fuel...

                      A classic case of category mistake if i ever saw one.

                      Buzzword BS'er if you ask me. I would be surprised if he researched for a
                      single day.

                      On Tuesday, March 26, 2013, Adrian Howard wrote:

                      > **
                      >
                      >
                      > On 26 March 2013 12:51, Allen Higgins <allen.higgins@...> wrote:
                      > > He concludes that methodologies give you what you want, i.e.
                      > > By considering that the Agile family and methods emphasize speed (not
                      > > feedback?) that they "have achieved their goal, and they are fairly
                      > quick."
                      >
                      > Anybody who still thinks agile approaches are primarily about speed
                      > are now an automatic fail as far as I'm concerned.
                      >
                      > (Note to self: I really must do something with that agile-myths.comdomain...)
                      >
                      > To be honest I no longer care that much about these sorts of
                      > meta-analysis. Somebody thing agile process don't work? Good. Thank
                      > you very much for the competitive advantage!
                      >
                      > Cheers,
                      >
                      > Adrian (who's feeling grumpy today ;-)
                      > --
                      > http://quietstars.com adrianh@... twitter.com/adrianh
                      > t. +44 (0)7752 419080 skype adrianjohnhoward pinboard.in/u:adrianh
                      >
                      >


                      [Non-text portions of this message have been removed]
                    • Ron Jeffries
                      Capers is a well known and pretty squared-away guy. I m not saying he s right, but he s not likely dishonest nor stupid. R ... Ron Jeffries
                      Message 10 of 22 , Mar 27, 2013
                      • 0 Attachment
                        Capers is a well known and pretty squared-away guy. I'm not saying he's right, but he's not likely dishonest nor stupid.

                        R
                        On Mar 27, 2013, at 9:14 PM, Leonardo Postacchini <notivago@...> wrote:

                        > Buzzword BS'er if you ask me. I would be surprised if he researched for a
                        > single day.


                        Ron Jeffries
                        www.XProgramming.com
                        If it is more than you need, it is waste. -- Andy Seidl



                        [Non-text portions of this message have been removed]
                      • Leonardo Postacchini
                        He is comparing oranges with apples, monkeys, oceans and DNA. He has a pretty impressive CV, i give you that. But authority fallacy aside, the article does not
                        Message 11 of 22 , Mar 27, 2013
                        • 0 Attachment
                          He is comparing oranges with apples, monkeys, oceans and DNA.

                          He has a pretty impressive CV, i give you that. But authority fallacy
                          aside, the article does not stand on its own meriths.

                          CMMI 1 + someting vs CMMI 5 + other?
                          CMMI is not a methodology, it is more like a measurement of methodology, or
                          rather adesion to any, that is to say he compared almost no adesion to one,
                          that is called no methodology at all, against fully organized whathever
                          other...

                          Using a metaphor: lets compare transport speeds:
                          1 - bicicle with lance armstrong
                          2 - drunken monkey on a car
                          3 - gasoline
                          4 - Granny Emma as certified iso truck passenger
                          5 - broken down rusty piece of junk formely F1 race car with adapted paper
                          combustion engine
                          ...
                          Conclusion race cars are slower than trucks and more acident prone than
                          bicicles.
                          ...
                          His list is simply absurd.

                          On Wednesday, March 27, 2013, Ron Jeffries wrote:

                          > **
                          >
                          >
                          > Capers is a well known and pretty squared-away guy. I'm not saying he's
                          > right, but he's not likely dishonest nor stupid.
                          >
                          > R
                          > On Mar 27, 2013, at 9:14 PM, Leonardo Postacchini <notivago@...<javascript:_e({}, 'cvml', 'notivago%40gmail.com');>>
                          > wrote:
                          >
                          > > Buzzword BS'er if you ask me. I would be surprised if he researched for a
                          > > single day.
                          >
                          > Ron Jeffries
                          > www.XProgramming.com
                          > If it is more than you need, it is waste. -- Andy Seidl
                          >
                          > [Non-text portions of this message have been removed]
                          >
                          >
                          >


                          [Non-text portions of this message have been removed]
                        • Adam Sroka
                          I think the problem is not with anyone s credentials but with the state of the art of research in our industry. ... [Non-text portions of this message have
                          Message 12 of 22 , Mar 27, 2013
                          • 0 Attachment
                            I think the problem is not with anyone's credentials but with the state of
                            the art of research in our industry.
                            On Mar 27, 2013 7:32 PM, "Leonardo Postacchini" <notivago@...> wrote:

                            > **
                            >
                            >
                            > He is comparing oranges with apples, monkeys, oceans and DNA.
                            >
                            > He has a pretty impressive CV, i give you that. But authority fallacy
                            > aside, the article does not stand on its own meriths.
                            >
                            > CMMI 1 + someting vs CMMI 5 + other?
                            > CMMI is not a methodology, it is more like a measurement of methodology, or
                            > rather adesion to any, that is to say he compared almost no adesion to one,
                            > that is called no methodology at all, against fully organized whathever
                            > other...
                            >
                            > Using a metaphor: lets compare transport speeds:
                            > 1 - bicicle with lance armstrong
                            > 2 - drunken monkey on a car
                            > 3 - gasoline
                            > 4 - Granny Emma as certified iso truck passenger
                            > 5 - broken down rusty piece of junk formely F1 race car with adapted paper
                            > combustion engine
                            > ...
                            > Conclusion race cars are slower than trucks and more acident prone than
                            > bicicles.
                            > ...
                            > His list is simply absurd.
                            >
                            > On Wednesday, March 27, 2013, Ron Jeffries wrote:
                            >
                            > > **
                            > >
                            > >
                            > > Capers is a well known and pretty squared-away guy. I'm not saying he's
                            > > right, but he's not likely dishonest nor stupid.
                            > >
                            > > R
                            > > On Mar 27, 2013, at 9:14 PM, Leonardo Postacchini <notivago@...<javascript:_e({},
                            > 'cvml', 'notivago%40gmail.com');>>
                            > > wrote:
                            > >
                            > > > Buzzword BS'er if you ask me. I would be surprised if he researched
                            > for a
                            > > > single day.
                            > >
                            > > Ron Jeffries
                            > > www.XProgramming.com
                            > > If it is more than you need, it is waste. -- Andy Seidl
                            > >
                            > > [Non-text portions of this message have been removed]
                            > >
                            > >
                            > >
                            >
                            > [Non-text portions of this message have been removed]
                            >
                            >
                            >


                            [Non-text portions of this message have been removed]
                          • Laurent Bossavit
                            ... That s starting to be better documented - see http://leanpub.com/leprechauns (disclaimer: this is a plug for my own book). One fun fact about Capers Jones:
                            Message 13 of 22 , Mar 28, 2013
                            • 0 Attachment
                              > I think the problem is not with anyone's credentials but with the state of
                              > the art of research in our industry.

                              That's starting to be better documented - see http://leanpub.com/leprechauns (disclaimer: this is a plug for my own book).

                              One fun fact about Capers Jones: he is the alleged source of an extremely laudatory quote about Scrum leading to "600% productivity improvements".

                              I emailed him (he turns out to be real nice and helpful) and he basically said "I can't possibly have written that, because no method I've looked at has done that".

                              My conclusion - no matter how impressive the credentials of the source of whatever stats you get thrown at you, always fact-check.

                              One issue with Capers Jones' data is that it's mostly based on and expressed in terms of Function Points, but rarely mentions the "dirty secret" of Function Points: that a good many of the empirical data points in such surveys are not based on *direct* measurement of FPs (using the approved methodology, which is somewhat involved), but on "backfiring" - that is, calculating an estimate of FPs based on a "lines of code" count. This can strike you as weird when you've read all the introductions to FPs that say counting lines of code is worse than useless.

                              Cheers,
                              Laurent
                            • JeffGrigg
                              ... I read the article. Well researched and well written. At least some of his results look rock solid. Some of it went of the deep end. But I m unable to see
                              Message 14 of 22 , Mar 30, 2013
                              • 0 Attachment
                                --- Ron Jeffries <ronjeffries@...> wrote:
                                > Capers is a well known and pretty squared-away guy. I'm not
                                > saying he's right, but he's not likely dishonest nor stupid.

                                I read the article. Well researched and well written. At least some of his results look rock solid.

                                Some of it went of the deep end. But I'm unable to see how or why.

                                It makes me wonder...
                                How do you do "pair programming with iterative" without doing XP or anything else shown in the paper? I've never heard of such a thing. And he claims to have a statistically significant number of C/C++ projects in the ~75k line/1k function point range that took this approach? Hmmm... It makes me wonder.

                                Is some of this a problem with his data?
                                He did limit it to C/C++ projects.
                                And that's been a pretty anti-agile culture for some years, from my experience.

                                If people are coding business applications in C (?!?!?!?) or even C++ in this, the 21st century, then maybe they need to have their ears boxed. [And as you may recall, I have a long C and C++ background. So I'm qualified to say that.]
                              • JeffGrigg
                                ... I have observed that pair programming, done badly, doubles cost with no obvious benefits. But done well, it starts with at least doubling the speed of the
                                Message 15 of 22 , Mar 30, 2013
                                • 0 Attachment
                                  --- Tim Ottinger <linux_tim@...> wrote:
                                  > * Pair programming does not double the cost. All the surveys
                                  > show that pairs complete in about half the time as individuals,
                                  > and that pairs tend to outperform their best members.

                                  I have observed that pair programming, done badly, doubles cost with no obvious benefits.

                                  But done well, it starts with at least doubling the speed of the better member. And it gets better from there. Motivating and empowering smart people can have large effects.


                                  And also, I've been surprised by how pairing has worked well in other disciplines outside of computer programming. It wasn't my idea, but I've watched teams outside I.T. try it, and be successful with it. Anything involving design or creation is a good candidate. Cleaning the toilets or taking out the trash... not so much so. ;->
                                • Theresa Jayne Forster
                                  Sorry been out of the loop recently so missed a few posts. it s not just one person watching , as if they were code-reviewing in real-time... That is how I
                                  Message 16 of 22 , Mar 30, 2013
                                  • 0 Attachment
                                    Sorry been out of the loop recently so missed a few posts.



                                    "it's not just "one person watching", as if they were code-reviewing in
                                    real-time..."



                                    That is how I was originally taught pair programming, The junior sits and
                                    watches the guru write his or her code..



                                    Obviously that is total poppycock.



                                    The last place I was told to watch another dev program on my first day.
                                    Within 15 minutes I was programming and getting through bugs quicker than
                                    the whole rest of the team. I asked the other dev to show me where they
                                    thought the bug was then I would show her where I thought it was then we
                                    discussed went to where we thought the bug was and fixed it. J

                                    Admittedly at that job I was woefully under used and not stretched at all.
                                    The Lead Dev was not as experienced as I was and the CTO refused to use
                                    Hibernate on principle.



                                    Theresa





                                    [Non-text portions of this message have been removed]
                                  • Adam Sroka
                                    ... obvious benefits. ... 2x assumes that if the pair were broken up they would both be as productive as the one is when the other is watching. In my
                                    Message 17 of 22 , Mar 30, 2013
                                    • 0 Attachment
                                      On Mar 30, 2013 12:35 AM, "JeffGrigg" <jeffreytoddgrigg@...> wrote:
                                      >
                                      >
                                      >
                                      > --- Tim Ottinger <linux_tim@...> wrote:
                                      > > * Pair programming does not double the cost. All the surveys
                                      > > show that pairs complete in about half the time as individuals,
                                      > > and that pairs tend to outperform their best members.
                                      >
                                      > I have observed that pair programming, done badly, doubles cost with no
                                      obvious benefits.
                                      >

                                      2x assumes that if the pair were broken up they would both be as productive
                                      as the one is when the other is "watching." In my experience, when you
                                      break up the pair they each spend twice as much time on facebook...

                                      I think the typical case is that the attention of the pair prevents a lot
                                      of waste, and the worst case is that the partner not paying attention is at
                                      least prevented from being elsewhere doing harm.


                                      [Non-text portions of this message have been removed]
                                    • Tim Ottinger
                                      ... All good and well, I suppose, but my biggest complaint with the article was that (regardless of how well written or how many numbers) it makes no sense.
                                      Message 18 of 22 , Mar 30, 2013
                                      • 0 Attachment
                                        > From: JeffGrigg <jeffreytoddgrigg@...>

                                        > I have observed that pair programming, done badly, doubles cost with no obvious benefits.

                                        > But done well, it starts with at least doubling the speed of the better
                                        > member. And it gets better from there. Motivating and empowering smart
                                        > people can have large effects.


                                        All good and well, I suppose, but my biggest complaint with the article was that (regardless of how well written or how many numbers) it makes no sense.

                                        It's like comparing if it's better to drive using a steering wheel, or on the highway. At some point you have to wonder what was he was smoking.



                                        Tim Ottinger <tottinge@...>
                                        http://industriallogic.com/
                                        http://agileotter.blogspot.com/


                                        >________________________________
                                        >
                                      Your message has been successfully submitted and would be delivered to recipients shortly.