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

RE: [XP] Re: Initial Planning and Metaphor

Expand Messages
  • Nick Robinson
    ... Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/
    Message 1 of 41 , Mar 1, 2003
      > -----Original Message-----
      > From: William Pietri [mailto:william@...]
      > Sent: 28 February 2003 20:02
      > To: extremeprogramming@yahoogroups.com
      > Subject: RE: [XP] Re: Initial Planning and Metaphor
      >
      >
      > On Fri, 2003-02-28 at 09:41, Nick Robinson wrote:
      >
      > > [...]How will we log exceptions? How will we raise notifications? How
      > > will we persist consistently. [...] I am begining to see the
      > > differences now, and in XP if a frameowrk is needed, it will be
      > built. If
      > > it isnt needed, it will not get built. If it doesnt get built, nobody
      > > epxended anything that didnt add value.
      > >
      > > I am trying to recall the conversation with the guy who mentioned
      > > frameworks in XP at the workshop. I believe he made a good point.
      > > [...] If he spent some time building the framework, then he would be
      > > able to add in all the pieces of development with ease and elegance.
      >
      >
      > His point is an excellent one, and his behavior is great in a non-XP
      > context. It is a dangerous behavior in XP. My tips for dealing with this
      > urge:
      >
      > Explain to him that in XP frameworks emerge through the relentless
      > removal of duplication. E.g., as soon as you have two exceptions being
      > logged, common functionality should be extracted out: there should be no
      > duplication between the cases. Since he has a keen eye for the benefits
      > of this, make it his responsibility to notice, comment upon, and fix any
      > duplication he finds.
      >
      > As he refactors, he will have a hard time not adding functionality that
      > he "knows" will be needed "soon". Ask him, as part of the experiment, to
      > not do that. But if that's too hard for him, then make a deal with him
      > about what "soon" means. E.g., that at first he's allowed to write stuff
      > that he's sure he needs this iteration. Then ramp that down to a day and
      > then an hour. And make sure to check him on it, too, and remove stuff
      > that doesn't get used within the limit.
      >
      > For me, much of the fear was I'd lose a good idea. If that's a problem
      > for him, ask him to make a quick write-up or sketch rather than writing
      > code. He will probably discover as I did: although making the sketch is
      > useful mental exercise, I almost never look at the sketches again.
      >
      > Another thing that irked me was a lack of symmetry or completeness.
      > E.g., if I needed a collection of User objects, I'd write both addUser()
      > and removeUser() even though removeUser was never called. These days I
      > generally just leave it out and trust that whomever needs the method
      > will add it. But a good middle ground is to put in a comment with the
      > method signatures that will come later:
      >
      > // todo: public void removeUser(User user)
      >
      >
      > I find that about half of those comments end up getting replaced with
      > real methods. That makes me happy, as I feel like I'm on the right
      > track. And about half of them get deleted, which also makes me happy
      > that I avoided doing unnecessary work.
      >
      >
      > Do you think that will help him?
      >

      Yes I do, thanks William. One reason I couldnt answer the question, was
      because deep down, as he explained his concepts and design about the
      framework, I could see why he had done it that way. A keen eye, and a good
      design. I couldnt answer the XP side because I couldnt see it as much as
      Chris couldnt. Now I can. I think there will be an intellectual epiphany
      one day by us all, when we *see* the benefits of TDD/Refactoring/Pair
      Programming/Team code ownership. Having questions like this is good. It
      means we are challenging our conceptualizations. Over time our
      appreciations for parts of our development world will be replaced with new
      conceptualizations. This challenging process will allow this process I am
      sure, and with some good experience with the TDD and refactoring etc, I am
      sure we will see how this all fits into place.


      Thanks again William.

      Nick.
      > William
      >
      > --
      > brains for sale: http://scissor.com/
      >
      >
      > 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/
    • Nick Robinson
      ... Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/
      Message 41 of 41 , Mar 2, 2003
        > -----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.