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

[XP] Re: Initial Planning and Metaphor

Expand Messages
  • Kiel Hodges <kielhodges@mindspring.com>
    ... seems ... But ... don t ... basically it ... all the time, ... what TDD does, ... TDD-driven ... like always. ... building ... the trivial ... You ve said
    Message 1 of 41 , Mar 1, 2003
    • 0 Attachment
      --- In extremeprogramming@yahoogroups.com, Ron Jeffries
      <ronjeffries@a...> wrote:
      > On Saturday, March 1, 2003, at 2:41:18 PM, Kiel Hodges
      <kielhodges@m...> wrote:
      >
      > >> Yes, that's one way, and perhaps a good way. I often prefer,
      > > though, to
      > >> build a trivial instance of the /real/ class. Mocks, it
      seems
      > > to me, often
      > >> wind up not matching the real thing, or feeling redundant.
      But
      > > maybe I'm
      > >> just not very good at them, which could be true since I
      don't
      > > do many.
      >
      > > Could you explain what you mean by "trivial instance of the
      > > /real/ class" and describe what one might look like for the
      > > example of the DB facade?
      >
      > Well, I'll try, but I'm not sure I can say much yet. I guess
      basically it
      > goes like this. When I'm working TDD, I build trivial classes
      all the time,
      > and then grow them up to be the real thing over time. That's
      what TDD does,
      > right?
      >
      > So if I happen to need a new class at some point, because my
      TDD-driven
      > implementation is calling for it. I just build a trivial class
      like always.
      > Sometimes I'll push down the first TDD and do a new generation,
      building
      > the classes "in parallel" for a while. Other times I just write
      the trivial
      > "subordinate" class and let it happen.

      You've said plenty! Thanks.

      > As for the DB facade itself, I'm even less sure than that.
      That's because I
      > don't think in terms of DB. (Odd thing for a person who has
      implemented
      > half a dozen real DB systems in his life, but there you are.) I
      think in
      > terms of collections of objects. If at some future time they
      have to live
      > in a DB, I'll discover that. Or I'll just persist them.

      I carried forward terms from the arlier discussion. I usually
      think in terms of persisting objects which might be collections
      or aggregates of other objects.

      But no matter. Your general explanation was more than adequate
      for me to understand your point. Thanks.

      Kiel Hodges
      SelfSo Software
    • Nick Robinson
      ... Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/
      Message 41 of 41 , Mar 2, 2003
      • 0 Attachment
        > -----Original Message-----
        > From: George Dinwiddie [mailto:programminglists@...]
        > Sent: 01 March 2003 16:29
        > To: extremeprogramming@yahoogroups.com
        > Subject: Re: [XP] Re: Initial Planning and Metaphor
        >
        >
        >
        >
        > Nick Robinson wrote:
        > >
        > >>Why would you create a class graph? Is the class graph just a
        > >>representation of the customer's experience and knowledge in the
        > >>domain? Why would the programmers want this on paper? Why would the
        > >>customer pay for it? Why not just ask the customer how their domain
        > >>works? How does having a class graph give you information about an
        > >>estimate?
        > >>
        > >
        > >
        > > Why would the customer want to pay for a class graph? Thats not
        > what I am
        > > alluding too. Forget XP a second - remember we are doing these
        > workshops as
        > > we dont know XP, and come from an RUP/UP background (or dare I
        > admit it an
        > > ICONIX background for some). These artefacts are what we have typically
        > > produced, and therefore thats why they are being mentioned in
        > the workshops.
        >
        > The question is "for whom are these artifacts produced and what need to
        > they have for them?" "Because we've always done it that way" is a weak
        > reason. You need to ask "why" again (and perhaps again, again) to
        > uncover the underlying reason, if there is one.

        I think you hit the nail on the head though. The "Because we've always done
        it that way" is a subconcious manifestation that affects the thinking when
        in a common situation were experience has been gained. In XP it is obvious
        such questions need to be answered, again and again to reinforce the point.
        In RUP certain documents are produced through the workflow, as they add
        value to the process and the team working that process (at least thats the
        idea though I have seen this fail).

        >
        > - George
        >
        > --
        > -------------------------
        > George Dinwiddie
        > agile programmer for hire
        > Baltimore/Washington area
        > gdinwiddie@...
        > -------------------------
        >
        >
        > To Post a message, send it to: extremeprogramming@...
        >
        > To Unsubscribe, send a blank message to:
        > extremeprogramming-unsubscribe@...
        >
        > ad-free courtesy of objectmentor.com
        >
        > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
        >

        __________________________________________________
        Do you Yahoo!?
        Yahoo! Tax Center - forms, calculators, tips, more
        http://taxes.yahoo.com/
      Your message has been successfully submitted and would be delivered to recipients shortly.