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

Re: [XP] Pair programming vs. Mentoring in a pair

Expand Messages
  • Ron Jeffries
    ... Yes ... I m referring more in my as yet imaginary paper to teams that just aren t as tight as they might be. You know the thing, they have their tests
    Message 1 of 79 , Apr 2, 2001
    • 0 Attachment
      Responding to Kenneth Tyler (09:47 PM 4/1/2001 -0700):
      >i
      >suspect that some businesses can pretend that their situation is not
      >changing and that they can afford to have people working who are not "alive"
      >to the real possibilities of the moment...but i am afraid that working in
      >such situations i would lose my real ability, which is to see change coming
      >and roll with the punches...and i can't afford to let "unlearn" it.

      Yes ... I'm referring more in my as yet imaginary paper to teams that just
      aren't as "tight" as they might be. You know the thing, they have their
      tests running at 100 _usually_, they _mostly_ pair program except for the
      guy who doesn't want to, they accept that their velocity is very low
      because all the developers are in meetings all the time, they refactor if
      they really have to ...

      They have the dials turned up to maybe 7, which gives them maybe half the
      effectiveness they could really have. Maybe it even feels good to them
      because in their previous lives the dials were turned up to around 3, and
      they're five times more productive than they used to be. But they could be
      so much more!

      I don't know that this is bad ... certainly I'm not perfecting myself as
      rapidly as I could be ... and yet it bugs me.

      So tell me, gentle reader: how good does a team need to be? How rapidly
      should they improve? When Jack won't pair program, and Jane releases code
      with the tests not working, should they just let it slide?

      Regards,

      Ronald E Jeffries
      http://www.XProgramming.com
      http://www.objectmentor.com
    • billy@psisys01.nrlssc.navy.mil
      ... Absolutely. If all a person got out of studying XP was unit testing, automated testing, and (especially) test-first programming, their productivity would
      Message 79 of 79 , Apr 9, 2001
      • 0 Attachment
        davechaplin@... wrote:

        > Responding to Ron Jeffries:
        > > Not in public. Anyone who has been around has seen teams differ by
        > > at least 10X, and probably has ideas as to why. I make no
        > > productivity claims for XP at all, at least not in terms of
        > > numbers. There's no way to know, AFAICS.

        > My personal experience is that by doing upfront testing and using
        > automated test harnesses you get a massive increase in productivity.
        > People spend more time building the new stuff, and less time fixing
        > what they have already apparently finished writing.

        Absolutely.

        If all a person got out of studying XP was unit testing, automated testing,
        and (especially) test-first programming, their productivity would almost
        have to improve.

        As far as "Silver Bullets" -- it seems that every year or so, there's a new
        methodology that promises to reduce defects, shorten delivery times,
        increase profits, and clean out that bottom left desk drawer that
        I'm afraid to look in anymore. One difference I see with XP is that
        although there *is* a coherent system, its elements (or at least some of
        them) are more or less decoupled. Certainly Continuous Testing,
        Simple Design, Refactoring, Continous Integration and the 40 hour week
        all stand on their own. In fact, I once thought I had invented
        Continuous testing/integration and Simple Design. I guess I should
        have written a book....

        --
        Billy Chambless
        Planning Systems Incorporated
        (228) 687-8745
        bchambless@...
      Your message has been successfully submitted and would be delivered to recipients shortly.