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

75622RE: [XP] YAGNI and iterative form of development

Expand Messages
  • William Pietri
    Jul 1 12:25 AM
    • 0 Attachment
      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/
    • Show all 74 messages in this topic