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

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

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