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

RE: [XP] YAGNI and iterative form of development

Expand Messages
  • William Pietri
    ... 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
    Message 1 of 74 , Jul 1, 2003
      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

      > 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.


      brains for sale: http://scissor.com/
    • 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, 2003
        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
        "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.