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

RE: Redesign vs. Refactor (Was Re: RE: [XP] Candidate for "Replac e Conditional With Polymorphism"?)

Expand Messages
  • Blum, Robert
    ... I don t think so - if you take a look at my (longish) post in this thread, I more or less migrated from the given solution to the alternate solution
    Message 1 of 1 , Mar 1, 2001
    • 0 Attachment
      > -----Original Message-----
      > From: Michael Larionov [mailto:michael.larionov@...]
      > Sent: Thursday, March 01, 2001 10:43 AM
      > To: extremeprogramming@yahoogroups.com
      > Subject: Re: Redesign vs. Refactor (Was Re: RE: [XP] Candidate for
      > "Replace Conditional With Polymorphism"?)
      >
      >
      > > There's an interesting general question here - is refactoring
      > > *always* preferable to redesigning, even when (setting myself up as
      > > devil's advocate) there is an alternative design clearly superior to
      > > the existing one and you have confidence that you can build the
      > > new design in and still have all the tests pass at the end ?
      > >
      > > (I know, it's a loaded question. It's intended that way.)
      > >
      >
      > Thank you for this question!
      > I also wonder when redesign and rewrite is better than refactoring.

      I don't think so - if you take a look at my (longish) post in this thread, I
      more or less migrated from the given solution to the alternate solution
      providing refactorings.

      I didn't set out to do it - things just became clearer and clearer. The code
      told me what to do. (Aahh - all those voices in my mind :-)

      > I don't worry so much about little redesigns, they usually go
      > through pretty smoothly.
      >
      > I would say they are almost the same as refactoring except
      > you have to write new unit
      > tests
      > and make sure you understand all business rules of the piece
      > you redesign.

      Shouldn't the UTs and ATs cover the business rules?

      [snip]
      > implications. We in our small group attempted "complete
      > rewrite" a few times
      > and it never was a complete success, we always miss deadline by 50%,
      > usually because of very lengthy QA phase.

      Out of curiosity - if you _always_ miss a deadline by 50%, isn't that a sign
      you should change your estimates in the future? (IOW - yesterdays weather;
      changed velocity)

      I think that 'yesterdays weather' is applicable to all sorts of estimates.
      It works better for short iterations, because even a huge mistake in initial
      estimation only causes a small change. Even if you're off by 50%, you're
      only off a week and a half, given you do three-week iterations.

      But it still works for bigger projects, at least in my experience.

      Bye,
      Robert
      --
      Disclaimer:

      This email may contain confidential information. If you have received this
      email in error, please delete it immediately,and inform us of the mistake by
      return email.

      Please be aware that messages sent over the Internet may not be secure and
      should not be seen as forming a legally binding contract unless otherwise
      stated.

      Also, please note that opinions expressed in this email are those of the
      author, and are not necessarily those of Midway Amusement Games LLC.
    Your message has been successfully submitted and would be delivered to recipients shortly.