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

Re: [XP] Re: Question about XP and Architecture (part 2)

Expand Messages
  • yahoogroups@jhrothjr.com
    ... From: calfred56 To: extremeprogramming@yahoogroups.com
    Message 1 of 1 , Jul 4 7:34 AM
      ----- Original Message -----
      From: "calfred56" <calfred.at.foliage.com@...>
      To: "extremeprogramming@yahoogroups.com"
      Sent: Friday, July 04, 2003 8:11 AM
      Subject: [XP] Re: Question about XP and Architecture (part 2)

      > John,
      > I couldn't agree more.
      > It sounds like what you're saying is that:
      > You Aren't Gonna Need It != You Aren't Gonna Need It Now

      YAGNI is one of those phrases that makes me cringe
      a bit, because the way it's phrased, it's very simple to
      get caught up in exactly that fruitless debate.

      Basically, the harder it's going to be to change, the more
      work you need to do to either

      1) try to avoid the need to change it


      2) try to make it easy to change.

      XP's attitude is to do the second if at all possible. It's
      pretty good at acomplishing that most of the time, too.

      > In some cases, the fact that you don't need a feature this week
      > (or this cycle) must get tempered by:
      > a. there's a pretty good chance that you will need it, eventually
      > b. at the time you will need it, there's a pretty good chance
      > that it will have an API impact, and
      > c. the API is clear, even though the implementation details
      > might not be.
      > In this case, putting the extended API in place is a risk reducer
      > that allows the API to remain stable through the point where the
      > feature is implemented.
      > I think that (a) and (b) are fairly straightforward judgements to
      > make. (c) can more difficult.

      I'm not so sure about # 1. In the case you cited, there's
      a perceived need for a higher reliability communication
      mechanism than the originally installed one. The thing is,
      if the original one isn't brain dead, it might actually
      satisfy the real reliability requirements, or turn out to be
      easily extended to do so.

      John Roth

      > Charlie
      > > This is one of those places where you have to assess
      > > risk: how much rework is going to need to be done if
      > > you change the interface definition? If it turns out to be
      > > relatively low, you plunge ahead. If it turns out to be
      > > relatively high, you buy some insurance by doing
      > > a more thorough job of analysis and interface design.
      > >
      > > John Roth
    Your message has been successfully submitted and would be delivered to recipients shortly.