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

Re: [XP] YAGNI and iterative form of development

Expand Messages
  • Vijay Krishnan
    William and Steven Thank you for the input !! Actually you pinned down the problem.. we are relatively newbies in XP.. We started off by adopting iterative
    Message 1 of 74 , Jul 1 2:09 AM
    • 0 Attachment
      William and Steven
      Thank you for the input !!
      Actually you pinned down the problem.. we are relatively newbies in XP..

      We started off by adopting iterative development,continuous
      builds,continuous testing,regression testing, .. and so on.
      But i guess the problem was the lack of preparation on starting this course.

      We should have adopted fully the tecniques of XP. but the i guess the
      inertia was a bit strong.
      What should be the ideal way in which an organization start of with XP
      practices.

      Can XP be initiated midway in a project

      Thanks!
      Vijay


      ----- Original Message -----
      From: "William Pietri" <william@...>
      To: <extremeprogramming@yahoogroups.com>
      Sent: Tuesday, July 01, 2003 12:55 PM
      Subject: RE: [XP] YAGNI and iterative form of development


      > On Mon, 2003-06-30 at 23:49, Steven Gordon wrote:
      > > I think we really need a concrete example of good, simple code without
      > > duplication for X1 and X2 that cannot be refactored into compatibility
      with
      > > X3 with significantly less effort than redesigning and reimplementing X1
      and
      > > X2.
      > >
      > > Without such an example, we will continue to say that this scenario
      cannot
      > > happen unless X1 and X2 were not implemented correctly using XP.
      >
      > I would strongly agree.
      >
      > That's not to say a beginning XP team won't get into that position,
      > though. XP says to refactor mercilessly, but at first it's hard to
      > understand just how merciless one has to be. Thus the frequent
      > recommendation that new XP teams bring in a coach.
      >
      >
      > Turning to the OP's question:
      >
      > > But sometimes due to deadline pressures, the prototype never reaches
      > > to the logical conclusion. As such implementation starts off with
      > > X1.... and so on..
      >
      > In XP, there is no "prototype". There is only "first version of the
      > system." If, due to deadline pressure, you make a shoddy first version,
      > then your succeeding versions are very likely to be shoddy, too. A
      > succession of shoddy versions can easily lead one to the
      > painted-into-a-corner scenarios you describe.
      >
      > Instead, an XP team makes a minimal but high-quality product. It may
      > only have one feature, and a small one at that, but it will work, the
      > code will be 100% tested, and the design will be exactly what you need
      > for X1. Deadline pressure in XP is handled by adjusting scope, not
      > sustainability.
      >
      > > consider u reach X3 stage and realise that even thought u have
      > > factored the code for X1, X2... X3 situation makes u realise that
      > > there is a flaw in the design itself.
      >
      > When adding Xn to a system perfectly designed for X(1 to n-1), the
      > design should usually seem imperfect. If Xn is like some existing
      > feature, then you will have to extract the duplication. If Xn is nothing
      > like any existing feature, then you will almost certainly have to
      > refactor to accommodate it.
      >
      > On the rare occasion where a new feature fits in without the smallest
      > amount of refactoring, I suspect myself of previous design gold-plating.
      >
      > > Now you are back to square 1 ( + 1 slightly better, as we atleast know
      > > what is reqd till X3) So wouldnt YAGNI approach postponing things
      > > result in such a dilemma
      >
      > In a word, no. You aren't back at square one, you're still just at X2,
      > looking to step to X3. If X3 is too far for a single step, you plan it
      > as a series of small steps, X2a, X2b, X2c, ... until you reach X3.
      >
      > Until you've done this a few times, it sounds ridiculous. Once you get
      > good at spotting duplication and factoring it out, once you have a good
      > grip on refactoring, it will make sense.
      >
      > This is similar to the experience of almost any physical challenge.
      > Whether a mountain seems easy to climb has very little to do with the
      > size of the mountain, and a lot to do with the kinds of mountains you
      > have climbed before.
      >
      > 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/
      >
      >
      >
    • Ron Jeffries
      ... Practice, man, practice! ... Wherever we want to. When we are faced with multiple forces and can only go one way, we have to choose. Practically every
      Message 74 of 74 , Jul 8 7:20 PM
      • 0 Attachment
        On Tuesday, July 8, 2003, at 2:07:23 PM, amr@... wrote:

        > This has been a very good discussion (at least for me). At this point in
        > time I will stop arguing a hypothetical example - it is just not working
        > here. It is hard to listen to 200 people tell you that you are wrong and
        > insist that you are right - although I really gave it my best shot :c)

        Practice, man, practice!

        > ...

        > Finally this brings me full circle - if many of your agree with Glen and
        > Dale that experience IS valuable. Then I pose this question:

        > "Where do we use our experience within the limits/boundries of TDD/XP?"

        Wherever we want to. When we are faced with multiple forces and can only go
        one way, we have to choose. Practically every choice we make is like that
        in one way or another.

        > More to the point - can our experience lead us away from pure TDD and
        > YAGNI in some circumstances?

        We can make that choice. I've been pushing YAGNI hard for years now, in
        "toy" programs ;-> and things always work out fine. The reason might be
        that recognizing what I want to put in early, I am sensitive to the first
        "legitimate" reason to put it in, so I don't go too far from what I might
        have done had I ignored YAGNI.

        > If not - then cool - I won't argue the point - I'm kind of burned out.

        > But if so - then where? What/when/where might things be tweaked to
        > incorporate our experience?

        Any time we want. All the time. It's just a rule.

        Ron Jeffries
        www.XProgramming.com
        "Some people take everything personally." -- Ron Jeffries
        "I do not!" -- Ann Anderson
      Your message has been successfully submitted and would be delivered to recipients shortly.