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

Re: [XP] Flow time, pair programming and collaborative environment

Expand Messages
  • Keith Ray
    I ll repeat an old msg I wrote about Peopleware: I just checked: Peopleware says that programmers spend 50% of their time collaborating with one other
    Message 1 of 66 , Sep 29, 2009
      I'll repeat an old msg I wrote about Peopleware:

      I just checked: "Peopleware" says that programmers spend 50% of their
      time collaborating with one other person, and 20% of their time
      working with two or more other persons -- right there on page 62 of
      the second edition. That's 70% of the time collaborating with one or
      more people. Way before pair programming was formalized.

      30% of the time are people "noise sensitive" to quote the book.

      The authors (at that time) believed that the state of "flow" was a
      solitary one, and necessary for sustained thinking and programming.
      The book seems to equate non-solitary with "interruptions".

      Pair programming allows "shared flow". And, as eating in any busy
      restaurant will demonstrate - talking with one other person
      effectively enables you to filter out the speech of everyone else.

      However, to some extent, I think "flow" may be over-rated: in that
      state a solo programmer can generate reams of code without noticing
      duplication or other code smells / design flaws. TDD helps make it
      solo coding better by making you alternate between creating and
      critiquing - but having another perspective provided by a partner
      provide more effective critiques.


      On Tue, Sep 8, 2009 at 3:09 PM, Ricardo Mayerhofer
      <ricardo.ekm.listas@...> wrote:
      > I'd like to see your opinion about this. TDM writes in peopleware about
      > flow, a immersion time dedicated to the work itself. He also argues how
      > interruptions are bad to productivity and proposes teams to watch how
      > many hours they can work uniterrupted. So my question is: Do still think
      > this is a good advice? How this relates to pair programming? Is it
      > possible to be in flow when pair programming?
      > How about collaborative environment? Considering that in a collaborative
      > enviroment, many times you are interrupted to help people to accomplish
      > their work.
      >
      >
      > ------------------------------------
      >
      > 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
      >
      >
      >
      >



      --
      C. Keith Ray, IXP Coach, Industrial Logic, Inc.
      http://industriallogic.com 866-540-8336 (toll free)
      Groove with our Agile Greatest Hits: http://www.industriallogic.com/elearning/
      http://agilesolutionspace.blogspot.com/
    • Keith Ray
      I ll repeat an old msg I wrote about Peopleware: I just checked: Peopleware says that programmers spend 50% of their time collaborating with one other
      Message 66 of 66 , Sep 29, 2009
        I'll repeat an old msg I wrote about Peopleware:

        I just checked: "Peopleware" says that programmers spend 50% of their
        time collaborating with one other person, and 20% of their time
        working with two or more other persons -- right there on page 62 of
        the second edition. That's 70% of the time collaborating with one or
        more people. Way before pair programming was formalized.

        30% of the time are people "noise sensitive" to quote the book.

        The authors (at that time) believed that the state of "flow" was a
        solitary one, and necessary for sustained thinking and programming.
        The book seems to equate non-solitary with "interruptions".

        Pair programming allows "shared flow". And, as eating in any busy
        restaurant will demonstrate - talking with one other person
        effectively enables you to filter out the speech of everyone else.

        However, to some extent, I think "flow" may be over-rated: in that
        state a solo programmer can generate reams of code without noticing
        duplication or other code smells / design flaws. TDD helps make it
        solo coding better by making you alternate between creating and
        critiquing - but having another perspective provided by a partner
        provide more effective critiques.


        On Tue, Sep 8, 2009 at 3:09 PM, Ricardo Mayerhofer
        <ricardo.ekm.listas@...> wrote:
        > I'd like to see your opinion about this. TDM writes in peopleware about
        > flow, a immersion time dedicated to the work itself. He also argues how
        > interruptions are bad to productivity and proposes teams to watch how
        > many hours they can work uniterrupted. So my question is: Do still think
        > this is a good advice? How this relates to pair programming? Is it
        > possible to be in flow when pair programming?
        > How about collaborative environment? Considering that in a collaborative
        > enviroment, many times you are interrupted to help people to accomplish
        > their work.
        >
        >
        > ------------------------------------
        >
        > 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
        >
        >
        >
        >



        --
        C. Keith Ray, IXP Coach, Industrial Logic, Inc.
        http://industriallogic.com 866-540-8336 (toll free)
        Groove with our Agile Greatest Hits: http://www.industriallogic.com/elearning/
        http://agilesolutionspace.blogspot.com/
      Your message has been successfully submitted and would be delivered to recipients shortly.