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

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

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