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

Re: [XP] Refactoring is the problem

Expand Messages
  • Dave Rooney
    Hi Joe, After I sent my first response, I decided to go back an re-read your original post. I do indeed think that this is a case where the person is pushing
    Message 1 of 91 , Oct 1, 2006
    • 0 Attachment
      Hi Joe,

      After I sent my first response, I decided to go back an re-read your
      original post. I do indeed think that this is a case where the
      person is pushing back against a 180 degree change in the way she was
      taught to develop software.

      During the summer after 1st year university, I built a small
      inventory management system for a group I was working with. It was a
      great environment, because I had the Customer sitting just a few feet
      away and had very rapid feedback at all times. I actually delivered
      that system in small increments as I completed functionality. Pretty
      cool concept for 1985.

      Fast forward to the summer of 1986. I came back to the same group
      and, as Customers do, they wanted new functionality and some new
      features. I had a look at the code and my first remark was, "Who
      wrote this crap?!" Well, I had nowhere to look but the mirror. So,
      before I made any functional changes, I refactored the code in the
      large way. As I did add new or improved features, I refactored even
      more. I just didn't know that was the name for it then.

      When I started doing contract work, the first couple of systems I
      worked on involved some pretty crappy code that I was brought in to
      rescue. In those cases, I either refactored or rewrote a lot of code
      in order to stabilize it or improve the design. That was in the
      early 90's.

      So, to me, refactoring is a natural act. I never (and I do mean
      never) look at code and assume that it will never change. I
      explained it to the Customers that the changes were needed in order
      to go forward. I also explained that I change my own code as I learn
      more about the problem domain - not just something that someone else
      wrote.

      That likely isn't everyone's experience. I do remember being told -
      as opposed to taught - in school that if it ain't broke, never ever
      touch it again. A lot of people likely took that to heart, and
      probably wonder why in hell we XPers want to change everything all
      the time rather than trying to get it right the first time!

      Does that make any sense?

      Dave Rooney
      Industrial XP Coach
      I n d u s t r i a l L o g i c, I n c.
      http://www.industriallogic.com
      http://www.industrialxp.org


      On 27-Sep-06, at 1:35 PM, J. B. Rainsberger wrote:

      > It was a simple change. Where we had one thing, we need a
      > collection of
      > things, so a Composite of sorts was the obvious implementation. We
      > test-drove the Composite, then when we plugged it in, it didn't
      > work. We
      > tried to plug it in /here/, but that didn't work either. We tried to
      > plug it in /there/, but it wouldn't fit. I wanted to test-drive a
      > drop-in replacement algorithm, but that would take too long. The code
      > simply won't flex enough to allow us to make the change.
      >
      > When we described this in the stand-up, someone decided to say, "Why
      > don't you just /code/ it instead of doing all this refactoring?!" I
      > have
      > no mouth, but I must scream.
      >
      > I believe that refactoring uncovers design problems. I observe others
      > acting as though they believe that refactoring /causes/ those design
      > problems. When I observe this, I feel that by choosing to teach I am
      > setting myself up for failure. My flight instinct kicks in. I don't
      > want
      > to abandon the many because of the behavior of the few, but that is
      > what
      > my heart is demanding of me.
      >
      > I don't know that I want to abandon being a consultant just yet.
      >
      > Any ideas?
      > --
      > J. B. (Joe) Rainsberger :: http://www.jbrains.ca
      > Your guide to software craftsmanship
      > JUnit Recipes: Practical Methods for Programmer Testing
      > 2005 Gordon Pask Award for contribution Agile Software Practice
    • Adrian Howard
      ... Now *that* made me laugh out loud. Adrian
      Message 91 of 91 , Oct 7, 2006
      • 0 Attachment
        On 6 Oct 2006, at 18:08, Ron Jeffries wrote:

        > Hello, adrianh quietstars. We email macros have been trying hard to
        > give Ron a more human on line appearance, a task whose magnitude we
        > frankly find daunting. We are glad to hear that we have at least
        > been able to amuse you, which is more than he has ever done.

        Now *that* made me laugh out loud.

        Adrian
      Your message has been successfully submitted and would be delivered to recipients shortly.