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

XP and AntiPaterns, second attempt

Expand Messages
  • 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 1 of 24 , Mar 30, 2000
      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

      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.