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

Re: [XP] Re: Do it by the book

Expand Messages
  • Elizabeth Keogh
    ... been ... work. ... of ... the new ... Heh. I ve worked in a couple of companies where - if you fixed the bug, you must have caused it in the first place
    Message 1 of 529 , May 1, 2007
    • 0 Attachment
      Ron wrote on 01/05/2007 03:38:00:

      > Hello, Steve. On Monday, April 30, 2007, at 1:49:30 PM, you wrote:
      >
      > > I think you have a good point. Most of the resistance I have seen has
      been
      > > more around the honest belief that such a set of practices just won't
      work.
      > > Especially the more experienced programmers. There is a certain sense
      of
      > > "been there, done that, didn't work" that gets in the way of trying
      the new
      > > thing.
      >
      > That really confuses me, unless they don't know what the practices
      > really are. The things we teach are the things that have always
      > worked.

      Heh. I've worked in a couple of companies where
      - if you fixed the bug, you must have caused it in the first place
      (collective code ownership doesn't work).
      - if you exposed the bug, you must have caused it in the first place
      (manual testing doesn't work).
      - if you pinned down the correct behaviour, you've made it impossible to
      change the code (automated testing doesn't work).
      - if you design simply, you're lazy and leaving as much work as you can
      for other people (simplicity doesn't work).
      - if you don't come in early and stay late, you're not committed (40-hour
      weeks don't work).
      - if you care more about what your customer wants than your manager,
      you're not a team player (stories don't work).
      - etc.

      If by 'always worked' you include getting fed up and leaving (or getting
      kicked out) and finding a more satisfying job, then yes, they always work.
      :D

      Cheers,
      Liz.

      --
      Elizabeth Keogh
      liz@...
      http://sirenian.livejournal.com
      http://jbehave.org


      [Non-text portions of this message have been removed]
    • 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.