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

[XP] Re: XP Soul, was: Tools and XP

Expand Messages
  • Arrizza, John
    ... Dave, I d just like to add a clarifying comment (at least I hope it is clarifying). An example of what I was trying to say: Other methodologies (OM)
    Message 1 of 9 , Mar 31, 2000
      > -----Original Message-----
      > From: Dave Thomas [mailto:Dave@...]
      > Sent: Thursday, March 30, 2000 1:47 PM
      > > - Attention to the right things at the right times: (I'm
      > afraid this is
      > > vague, but here goes anyway...)
      > I think this is a good point, but I'm thinking that we should be able
      > to drive this out of the other points, in that failing to do it (for
      > example) causes us to fail to deliver immediate value.

      I'd just like to add a clarifying comment (at least I hope it is
      clarifying). An example of what I was trying to say: Other methodologies
      (OM) contact the customer once at the beginning of the development cycle for
      their requirements and once at the end for their signoff (don't forget the
      money!). XP does the "right thing", i.e. contact the customer, and does it
      at the "right times", i.e. at the beginning of every iteration. I wanted to
      capture that and make sure that it was explicit and so contrasted with OMs
      lack of contact with the Customer.

      When and how often something is done has a profound influence on the success
      of development. Another example: I have worked developing shrink-wrapped
      software and it is sometimes suggested by developers that a "clean up
      release" is done. In other words, no new features, just fixes and clean up
      (read: refactoring) of the current code base. Management invariably shies
      away from it (my favorite: "if it ain't broke, don't fix it"), customers
      don't want to pay for it, and the developers cringe at the thought of adding
      new code for the next release. They start dropping bigger and louder hints
      to management or just leave the company. Eventually, after a few releases,
      the new features become so hard to write, that there is a shouting match and
      management after a long while (they hesitate even then) capitulates and the
      entire code base is re-written. Of course, you can never capture all the
      business rules that were in the original code base because they are
      scattered from here to eternity. So the first few releases are pretty
      crappy, lots of little bugs all over the place (QA and the developers take a
      big hit from management). The "bright and shiny" new release promised by the
      marketing boys comes across to the customer as pretty lousy, causing your
      companys credibility to go down the toilet. After a few more patch releases,
      you've got the code almost back to where it was and you can now start adding
      more features again. But the customers never *really* trust you again like
      they did before.

      Compare that to RefactorMercilessly.

      As far as I can see the difference is in timing. Both XP and the OMs
      (eventually) do the same activities, the frequency and timing is what
      changes. I would like to capture that difference as part of the soul of XP.

      John A
    Your message has been successfully submitted and would be delivered to recipients shortly.