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

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

Expand Messages
  • 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 1 of 22 , Mar 27 6:31 PM
    • 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 2 of 22 , Mar 27 7:32 PM
      • 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 3 of 22 , Mar 27 7:37 PM
        • 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 4 of 22 , Mar 28 12:36 AM
          • 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 5 of 22 , Mar 30 12:27 AM
            • 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 6 of 22 , Mar 30 12:35 AM
              • 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 7 of 22 , Mar 30 12:48 AM
                • 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 8 of 22 , Mar 30 1:05 AM
                  • 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 9 of 22 , Mar 30 2:18 PM
                    • 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.