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

[XP] Re: Is this a cult?

Expand Messages
  • Phlip
    From: Chris Bitmead ... There are those who practice XP. Just as there are those who practice C++ or podiatry or transmission maintenance. There are those
    Message 1 of 24 , Mar 29, 2000
    • 0 Attachment
      From: Chris Bitmead

      > Can you in any way justify this posting? Or are you in a "whining cult"?

      There are those who "practice" XP. Just as there are those who "practice"
      C++ or podiatry or transmission maintenance.

      There are those who do not.

      Because XP does not yet have critical mass, those who like it feel it should
      grow more awareness and acceptance in the programming industry.

      XP is not really a methodology - it's not a system of defining Objects in an
      OO program. It's a workflow; an exact recipe of day-to-day and
      minute-to-minute behaviors; territory the traditional methodologies avoid
      because they don't want to "cramp anyone's style". This leaves those who do
      not understand XP yet mystified by the details and buzzwords used to
      describe a workflow, when they are looking for (or maybe seeking shelter
      from) a traditional methodology. And if they have picked up our square peg
      and tried to put it into the round mental hole they use to understand
      methodologies, it won't fit. This leaves them wondering why we say what we
      say in the way we say it.

      XP uses "System Metaphors" to generate its jargon. This is much better than
      jargon pulled together at random from various sources, the traditional way.
      (And XP recognizes the critical team-building role of an internal language.
      This role is documented in pre-XP literature.)

      Because XP users want more people to be aware of XP, the users perform
      "promotion" techniques.

      The SystemMetaphor for the promotion of XP is "Religious Evangelism".

      Superficially, everything in the "XP Promotion Project" maps onto a
      religious or quasi-religious popular concept. The Twelve Principles become
      The Twelve Commandments (my bad on that one), those who refuse to try to
      understand XP beyond the individual principles are "infidels"; those who
      understand XP to the satisfaction of insiders are "novices"; those who
      preach XP are "zealots", etc.

      In the details, XP is technology, not religion. Suffice to say there's a big
      difference, starting the the concept of unquestioning faith.

      SystemMetaphors are always good things, so long as everyone understands they
      are _metaphors_.

      If someone uninitiated into the XP cult hears jargon like "someone
      uninitiated into the XP cult", they - by definition - have not learned what
      a SystemMetaphor is or how it's used to generate jargon.

      So they take the terms literally.

      In communications among XP practitioners, the Evangelicism SystemMetaphor
      serves its purpose. But in open communications intended for the uninitiated,
      this particular SM causes great damage, due explicitely to the amount of
      advertizing for various religions everyone in modern society has inoculated
      themselves against.

      /After years studying astrology, you are finally led into the deepest cave
      in your part of Europe. You are shown a dome ceiling painted with silvered
      stars. Your guide explains 'that's Perseus [Orion], and this is Taurus.
      Thousands of years ago the Mesopotamians recorded that Spring started while
      the Sun was in Taurus. But Perseus slew Taurus, and now Spring starts in
      Aries. Get it? Perseus rotated the entire Universe!'/

      Phlip
      ======= http://users.deltanet.com/~tegan/home.html =======
    • Ron Jeffries
      ... That would be the standard thing to do in a product organization. ... How does that work compared to finding out in minutes what they like? Ron Jeffries
      Message 2 of 24 , Mar 30, 2000
      • 0 Attachment
        At 09:32 PM 3/30/2000 -0500, you wrote:
        >So how do we accurately meet the requirements of our customer(s).
        >I tend to think that we're going to need a surrogate for the customers.
        >We call them "product analysts" in my organization. That product
        >analyst can do a full requirements phase with a reasonable number of
        >customers, document it, and then get on the team as a surrogate
        >customer and work through the iterations with us.

        That would be the standard thing to do in a product organization.

        >We currently do some iterative development like this. Eventually we
        >get Beta's out to customers, although the communication with them is
        >typically just phone and E-mail. We don't do much on-site with them and
        >they rarely come on our site to work with us.

        How does that work compared to finding out in minutes what they like?



        Ron Jeffries
        www.XProgramming.com
      • Daniel T.
        A recent post on comp.object got me thinking about this subject so I started doing some re-reading over the weekend. I would like to start up a discussion
        Message 3 of 24 , Mar 30, 2000
        • 0 Attachment
          A recent post on comp.object got me thinking about this subject so I
          started doing some re-reading over the weekend. I would like to start
          up a discussion about some of the AntiPatterns listed in the book by
          Brown et al., how they affect XP and how problems might be fixed...

          For those not in the know. An antipattern is formed when a solution
          to a perceived problem causes a completely different problem that is
          even worse.

          Quickly perusing the book, I find that XPs practices seem to do a
          good job of protecting the project from all of the antipatterns in
          chapter five (which deals with development level issues,) however
          there are several antipatterns in chapter 6 that need to be watched
          for, namely... (Chapter 6 deals with Architecture issues.)

          Architecture by Implication (a system developed without a documented
          architecture.) As I understand both XP and the antipattern (and I'm
          not claiming to understand either all that well.) XP has several
          methods to help insure this antipattern doesn't come about. Namely
          the system metaphor, planing game, stand--up meetings and
          pair-programming (BTW I'm beginning to see pair-programming in a
          different light, maybe more on that later.) However only the system
          metaphor addresses this antipattern explicitly.

          Design by Committee (Committee designs are overly complex and lack a
          common architectural vision.) Again, XP relies on communication to
          avoid this. That and the fact that a committee isn't needed to change
          the design, just one pair with a lot of time on their hands. :-)

          Reinvent the Wheel (Legacy systems with overlapping functionality
          don't interoperate. Every system is built in isolation.) I have
          strong reservations about this one, especially after Mr. Beck's
          comments on a "money" class. Although framework reuse seems to be
          lauded by XPers (especially the "unit" framework.)

          Stovepipe Enterprise (Uncoordinated software architectures lead to
          lack of adaptability, reuse, and interoperability.) XP doesn't seem
          to have any processes to address this antipattern. I feel that XP
          should take definite measures to address this issue or it could
          easily be a problem.

          Grand Old Duke of York (Four out of five developers cannot define
          good abstractions; this leads to excess complexity.) XP could clearly
          suffer on this front (and I'm not just saying that because I'm one of
          those "abstractionists" that the book talks about. Some people are
          better at coming up with great frameworks and some are better at
          coming up with great algorithms. It makes sense to have a formal
          system in XP to recognize this fact and allow "framework gurus" some
          explicit say in the design of the program... These people would be
          better off in the cat-bird seat instead of on the keyboard for
          instance...

          Jumble (Interface designs are an unfactored mixture of horizontal and
          vertical elements, which necessitates frequent interface changes and
          an inability to reuse.) Not only does XP not address this
          antipattern, XP seems to claim that it doesn't exists! Or at least
          that the "frequent interface changes" that this antipattern involves
          are cheap enough not to be a real problem...

          The chapter seven antipatterns are all "people issues". As such, in
          most cases I don't feel that *any* "design method" should or could
          protect against them. XP however seems as though it would be
          especially vulnerable to:

          The Feud (Managers who engage in protracted conflicts with peers have
          serious negative impacts on their staffs.) In XP's case, sorting the
          "managers" from the "staff" might be a little difficult. I guess the
          coaches job primarily is head off these kinds of problems.

          Irrational Management (Habitual indecisiveness and other habits
          result in de facto decisions and development emergencies.) XP seems
          to revel in "de facto decisions" calling it "let the code tell you
          what needs to be done". Again, it seems the only one to ensure
          against this problem is the coach...

          =====================================================================

          In case someone missed it above, I must again say... There are many
          antipatterns discussed in the book, XP has clear and effective (IMO)
          methods to stave off many, if not most of them (especially the
          "development antipatterns".) I've only covered the ones that I
          personally perceive as potential problems in a typical XP project
          (assuming that the XP book describes "typical" XP projects. :-)

          I would like to here what people using XP think. What XP practices do
          you think address the potential problems above? How? Why?
        Your message has been successfully submitted and would be delivered to recipients shortly.