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

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

Expand Messages
  • 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 1 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 2 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 3 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 4 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 5 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.