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

42926Re: [XP] Do Good Work -- Zen Computer -- refactoring legacy code

Expand Messages
  • jeffgrigg63132
    Feb 4, 2002
    • 0 Attachment
      > Robert Watkins wrote:
      > [...]
      > Deciding wether or not to spend the significant amount of [time]
      > to refactor this legacy system _is_ a business decision, I think.

      --- Ron Jeffries <ronjeffries@a...> wrote:
      > Yes, and no. Refactoring in a lump, yes. [...]
      > refactoring in a lump /is/ a business decision, [...]
      > Refactoring as you go is IMO always a technical decision and
      > always the right thing to do. [...]

      The way I see it, when they foist bad code on me, I have a right to
      spend as much time refactoring ("improving the design of existing
      code without changing its functionality") as the time I spend adding
      customer-requested functionality. Up to that 50%/50% split, I say
      it's a technical issue and I don't ask or tell.

      I see investing *more* time to cleaning up the bad code as a business
      decision. So it's up to the customer to decide if and when to do it.

      My experience has been that the only way for a customer to address
      this issue has been to propose an entire iteration devoted to fixing
      the existing bad code. But I've never been happy with the result:

      1. If they decide not to refactor, they'll still blame you for the
      bugs and slow development time.

      2. If they opt for a refactoring iteration, then the customers have
      no incentive to accept delivery of the iteration, because it doesn't
      include any new features they asked for. From their perspective,
      upgrading the software may break something they're currently using.
      And as for the bugs you're fixing -- from their perspective, those
      were all your fault anyway.

      3. After the cost and pain of a refactoring iteration, even if
      everything goes well, many customers will have the expectation that
      everything is perfect now: So all the legacy problems that you
      didn't have sufficient time or money to fix are now "really really
      your fault."

      These are all lose-lose results.

      I've had the most success with iterations that deliver both
      functionality and improved structure (refactoring). A visible
      improvement in the reliability and maintainability of the system over
      time will make the users happy and will make you popular. They don't
      have to know how you did it. ;->
    • Show all 67 messages in this topic