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

Do it by the book

Expand Messages
  • Manuel Klimek
    Ron, ... Do you actively support this, or does it just happen to be in your signature database? For me it reads like put processes over people , e.g. don t
    Message 1 of 529 , Apr 16, 2007
    • 0 Attachment
      Ron,

      On 3/25/07, Ron Jeffries <ronjeffries@...> wrote:
      > Ron Jeffries
      > www.XProgramming.com
      > My advice is to do it by the book, get good at the practices, then do as
      > you will. Many people want to skip to step three. How do they know?

      Do you actively support this, or does it just happen to be in your
      signature database?
      For me it reads like "put processes over people", e.g. don't let the team
      decide what to introduce when, but force them to use XP
      by the book now. This is one of the most common reasons I heard
      people state why XP didn't work out for them: Management said
      "do XP", nobody understood the reasons of the practices
      involved, nobody recognized the problems and benefits and
      because it was forced by management there's a great deal
      of doubt involved.
      Why not learn the practices (as a team), analyze your problems, and choose
      the practices that you think address the problems you identified?
      I think that for most teams this may lead to full blown XP "by the
      book", on a relatively safe path.
      Some teams may even have better processes than XP. How do you know?

      Cheers,
      Manuel
    • Murali Krishna Devarakonda
      ... You are right, of course. But my list was only intended to illustrate and discuss the idea - not to discuss the list itself. I really wanted to focus on
      Message 529 of 529 , May 6, 2007
      • 0 Attachment
        --- In extremeprogramming@yahoogroups.com, "Kelly Anderson"
        <kellycoinguy@...> wrote:
        >
        > On 4/29/07, Murali Krishna Devarakonda <muralikd@...> wrote:
        > > Over the last two decades, I've seen resistance to practically every
        > > "successful" technology-framework-process-whatever first-hand.
        ...
        >
        > > Yet, to simplify , why do programmers "zealously" resist change-
        > > particularly in those cases where we can now say with hindsight that
        > > it was for the better, i.e. "successful"?
        >
        > Just because something is eventually successful, does not necessarily
        > mean that early adoption means early success. In fact, you could
        > probably make an effective argument against early adoption of
        > development tools/methodologies. Look how much has been learned by the
        > bleeding edgers, and use what has been proven to work is a reasonably
        > successful way to go for many endeavors.
        >
        > -Kelly

        You are right, of course. But my list was only intended to illustrate
        and discuss the idea - not to discuss the list itself. I really wanted
        to focus on "successes" and discuss what goes on in the minds of
        programmers who resist the *idea* behind the product that eventually
        becomes a "success".

        I'm going to post my thoughts on this in another thread.
      Your message has been successfully submitted and would be delivered to recipients shortly.