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

[extremeprogramming] Re: Elves in the Night [Stupid XP Question Number 6614]

Expand Messages
  • Robert C. Martin
    Hans Wegener wrote in message news:38707FEB.EF168122@credit-suisse.ch... ... need now, ... Will this ... that. The ... it, and
    Message 1 of 38 , Jan 3, 2000
      Hans Wegener <hans.wegener@...> wrote in message
      news:38707FEB.EF168122@......
      > "Robert C. Martin" wrote:
      >
      > > XP resolves the dilemma by saying: Pay only for what you know you
      need
      now,
      > > pay for generality now, when you need the generality now.
      >
      > I don't see how XP really resolves anything if you mean the dilemma:
      "Will
      this
      > feature pay off or not?" People are notoriously bad at predicting
      that.
      The
      > principle merely puts tention in the decision to go meta, as you said
      it,
      and
      > that's a very good thing to do. Yet, as I read your words you mean to
      say
      that
      > you are only willing to pay for what you need right now. IMHO that's
      another
      > word for shortsightedness. This is not to say XPers are shortsighted
      persons -
      > not at all. But the principle doesn't aid you in becoming more
      farsighted,
      and
      > from time to time this is really what you need.

      XP defines shortsighted to mean: "you got caught a third time." In
      other
      words, if it happens once, you pay for it. If it happens twice you
      figure
      it'll happen again, and you generalize it. If you find yourself paying
      a
      third time, you screwed up.

      > The problem becomes less fuzzy when you take a look at project size
      and
      domain
      > complexity: lack of domain knowledge and sheer complexity are major
      reasons for
      > running over budget etc. We all have heard, read or even witnessed
      these
      > stories. Starting small and releasing early and often is one of the
      best
      > countermeasures. In such situations a wrong decision (on average) has
      also
      a
      > comparatively small effect. Go YAGNI. But if I knew the beast well and
      had
      > things under control I would be foolish not to start and think big.
      Here
      YAGNI
      > would (again on average) be more expensive.

      I'm not convinced of that. The overall cost of building the project
      *might*
      be higher; however there is another factor. If you work only on those
      things that are most important to the customer, the customer starts to
      get
      benefit early. That benefit starts to pay for the cost of the project
      before the project is complete. Thus the net cost may be lower.

      XP says: "Generate value for the customer every day. Generate the
      greatest
      value early. Don't invest in infrastructure until you are damned sure
      that
      it will help you generate more value for the customer *sooner* rather
      than
      later."
      >
      > Wrapping up, you have to relate things to the problem at hand. In some
      > situations XP really makes perfect sense. But there are many others
      where
      XP
      > adds to the risk instead of reducing it. The art is to tell where the
      borderline
      > is, and that is still a matter of experience, not of process.

      I can't imagine a scenario in which XP adds risk. I consider the risk
      of
      building the wrong infrastructure up-front to be greater than the risk
      of
      waiting until the need for the infrastructure is demonstrable.

      --

      Robert C. Martin | OO Mentoring | Training Courses:
      Object Mentor Inc. | rmartin@... | OOD, Patterns, C++,
      Java,
      PO Box 85 | Tel: (800) 338-6716 | Extreme Programming.
      Grayslake IL 60030 | Fax: (847) 548-6853 |
      http://www.objectmentor.com

      "One of the great commandments of science is:
      'Mistrust arguments from authority.'" -- Carl Sagan
    • Robert C. Martin
      Tom Kreitzberg wrote in message news:387364E4.C0A3E6CC@jhuapl.edu... ... There is no fundamental difference between pre XP Object
      Message 38 of 38 , Jan 5, 2000
        Tom Kreitzberg <Tom.Kreitzberg@...> wrote in message
        news:387364E4.C0A3E6CC@......

        > But I think "flexibility" means different things to XP and,
        > shall we say, pre-XP OMA. In XP, doesn't it primarily mean
        > once and only once? In pre-XP OMA, doesn't it primarily mean
        > OCP and low coupling? When I wrote that XP "is structured so
        > that inflexible designs are cheap to change," I meant inflexible
        > in this second sense.

        There is no fundamental difference between pre XP Object Mentor, and
        post XP
        Object Mentor except that we have identified XP as the process we like
        to
        use. Even this is not a big shift for us, since XP is very similar in
        spirit and practice to the unnamed process we have used for years.
        There
        are differences, certainly -- specifically in the areas of pair
        programming
        and test first programming; but these are differences in intensity, not
        in
        philosophy. As for the rules governing simplity, the planning game,
        quick
        iterations, etc, we were very closely aligned.

        Flexibility means the same to me now as it did five years ago. The
        ability
        to add or change significant amounts of functionality while changing a
        minimum of exsiting code -- i.e. the OCP. OnceAndOnlyOnce leads to this
        goal just as the OO design principles do. It is my goal over the next
        several months to integrate the principles and XP.
      Your message has been successfully submitted and would be delivered to recipients shortly.