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

Re: [XP] Refactor with mercy.

Expand Messages
  • Ron Jeffries
    ... I have seen those things be problems in real life, in teams that were trying to do [something like] XP. I have had a team take some of its top people and
    Message 1 of 49 , Sep 2, 2005
      On Friday, September 2, 2005, at 11:06:42 AM, Phlip wrote:

      > Ken Boucher wrote:

      >> I think we can improve the number of features we deliver if we do the
      >> following:
      >> quit refactoring code that truly is good enough.
      >> quit refactoring code that has nothing to do with this iteration.
      >> quit refactoring code just because we learned something new this week
      >> quit looking for sections of code to refactor just because we like
      >> refactoring.
      >>
      >> Try it. It might improve XP.

      > Have you had a problem with those in real life?

      I have seen those things be problems in real life, in teams that
      were trying to do [something like] XP. I have had a team take some
      of its top people and undertake a 40-working-day refactoring, for
      example.

      Refactoring is fun, and sometimes implementing stories is less fun.
      I can imagine teams doing too much of it, and take that to be part
      of what Ken is concerned about.

      Ken mentions several kinds of refactoring that he thinks should be
      quit. I'm not sure that "Refactor Mercilessly" is canon, and I'm
      sure it was never intended to be taken as meaning something like
      "refactor endlessly, never doing anything else." But Ken's notions,
      though my dear friend presents them as if they were better canon,
      also require significant judgment:

      >> quit refactoring code that truly is good enough.

      This one seems clearly to me to be a matter of judgment. We can
      submit our code to some arbiter of "good enough", but otherwise each
      team, and each individual needs to learn what "good enough" means.

      I would guess that one way to learn what good enough means is to
      work well past it into "way too good".

      Others' experience may vary, but my experience is that there is a
      lot of code out there that isn't good enough, and very little that
      is way too good.

      >> quit refactoring code that has nothing to do with this iteration.

      Personally, I mostly agree with this in principle. Even so, I offer
      two notions that would seem to produce refactorings "outside" the
      current iteration plan:

      Often the refactoring that we need for our story reaches beyond
      the code that we would change if we were just going to hammer the
      story in. We need to follow where the refactoring leads: if we
      propose to change the protocol for some method, it may well be
      best to change all the senders.

      Sometimes we have written code that is beneath our personal
      standards. Maybe we let ourselves feel too much pressure; maybe we
      had too much Nyquil the night before. (Ever notice how much Nyquil
      and Creme de Menthe look alike?) Once we pass all the bars on
      Accountability and start moving toward Responsibility, we may feel
      the need as a matter of professionalism to fix what we have done
      poorly. In my opinion, we should honor that feeling; indeed, we
      should cherish those who feel it.

      >> quit refactoring code just because we learned something new this
      >> week

      The notion of learning, in this context, as already been mentioned
      by some of my wise colleagues. I would just underline that it's
      pretty risky to discourage people applying what they have learned. I
      understand the XP value called "Feedback" to be about providing the
      opportunity for learning, and I believe that the intention should be
      to pick up on the opportunity whenever we can.

      >> quit looking for sections of code to refactor just because we like
      >> refactoring.

      Ken, you yourself mentioned happiness as a metric you care about. If
      a programmer likes refactoring, a bit of their happiness may be tied
      up in that activity. I'd like to see an organization find a way to
      honor that source of happiness, not suppress it.

      > In real life, I have a problem with leaving too many "TODO" comments all
      > over my code. Had a good idea to improve, wrote "TODO", didn't get back to
      > it.

      Me too. In the teams I visit, there are occasionally spikes of
      refactoring that I would consider to be excessive. Much more
      commonly, however, the code is allowed to get worse and worse over
      time.

      Agile methods cannot work if the design quality is not kept "good
      enough". A team needs to be very sensitive to this notion, and,
      frankly, I feel that the majority of programmers are not
      sufficiently skilled even to recognize what's good enough.

      Ron Jeffries
      www.XProgramming.com
      Only the hand that erases can write the true thing. -- Meister Eckhart
    • Ron Jeffries
      ... I ve heard of this in the urban legend sense. Never seen it really happen beyond a cycle or two around the loop. Anyone else? Ron Jeffries
      Message 49 of 49 , Sep 14, 2005
        On Wednesday, September 14, 2005, at 5:28:27 PM, Jeff Grigg wrote:

        > I've heard of teams that get into refactoring wars -- first going
        > one way, and then the other. The warring parties need to talk to
        > each other. Maybe they need to agree on something, and establish a
        > coding standard.

        I've heard of this in the urban legend sense. Never seen it really
        happen beyond a cycle or two around the loop. Anyone else?

        Ron Jeffries
        www.XProgramming.com
        No one expects the Spanish Inquisition ...
      Your message has been successfully submitted and would be delivered to recipients shortly.