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

[XP] fix or rewrite?

Expand Messages
  • Chris Bitmead
    What do people think? If a project has been pretty soundly bodged, but somehow has been able to be patched together with duct-tape and chicken wire, is there
    Message 1 of 5 , Apr 2 6:38 PM
    • 0 Attachment
      What do people think? If a project has been pretty soundly bodged, but
      somehow has been able to be patched together with duct-tape and chicken
      wire, is there any hope of incrementally fixing it to come up with
      something of quality, or should it always be thrown out and re-done?

      Companies never like to admit they screwed up and have blown their $$.
      On the other hand I usually think a project that has gone way off-course
      is unrecoverable, or at least uneconomic to recover. But then
      programmers like new code, so maybe I'm biased. What do others think?
    • Arrizza, John
      ... Interesting you should ask, as that is where we are now. We are trying XP in a new part of the project (a rewrite of some small functionality) and at the
      Message 2 of 5 , Apr 3 5:59 AM
      • 0 Attachment
        > -----Original Message-----
        > From: Chris Bitmead [mailto:chrisb@...]
        > is there any hope of incrementally fixing it to come up with
        > something of quality, or should it always be thrown out and re-done?
        >
        > Companies never like to admit they screwed up and have blown their $$.

        Interesting you should ask, as that is where we are now. We are trying XP in
        a new part of the project (a rewrite of some small functionality) and at the
        same time I've been using Unit tests and refactoring to clean up some code
        (i.e. fix bugs).

        In my experiences so far with rewriting the hard part is the unit tests.
        Since the old code was NOT written with testing in mind, the first step
        invariably is to refactor the class to disentangle itself from the rest of
        the spaghetti. Once I have a clean strand, I write a unit test for it. I
        know this is a break from TestBeforeYouRefactor, but if I could write the
        test without refactoring I would have done it. This is risk#1: you are
        making changes to the code without a unit test back up.

        I then write as many tests as I can think of. Can I find them all? I don't
        know. I don't know precisely what the original code did since I did not
        write it in the first place or it's mine but I've forgotten what it does. Of
        course, there are no tests I can run to see what the code does. This is
        risk#2: you don't know what the original code does and you are changing it.

        I then refactor everything in the class as best I can. Sometimes I discover
        some boundary conditions as I do this and add more tests. I may have to
        refactor calling/caller classes to adhere to the new code. I know you
        shouldn't in general change the interface during a refactoring session, but
        the changes I make are done reluctantly and carefully (as if that means I
        won't introduce a bug hah!). Eventually I will add unit tests for these
        other classes -- or not. This is risk#3: you may have to change surrounding
        classes without a unit test back up.

        There are no functional tests except to crank the entire system up and let
        'er rip. You may, if you're lucky, be able to deduce your new code is
        running correctly but you do not know for sure because there are no
        functional tests that help you target your function specifically. You may
        have, for example, fixed a "bug" that other code depended on. If that other
        code breaks during functional testing Great! if not, you will be blamed for
        "introducing" a bug when this is all discovered by your 1000 customers
        scattered throughout the world. This is risk#4: you don't know what the
        original code was supposed to do, and you don't know if the code and unit
        tests you just wrote replicate that functionality.

        All of this takes a LONG TIME, much much longer than if it were done
        correctly the first time by the people writing the code. Managers are
        wondering what I'm spending all my time on. This is risk#5: it takes a long
        time, you may be fired.

        In answer to your question, I have yet to see a rational, non-joking manager
        agree to rewrite an entire system unless the situation is hopeless.
        Hopeless, that is, from his point of view not yours. As you said, "... never
        like to admit they screwed up", why would any sane manager agree to a
        rewrite and thereby blatantly admit they couldn't get it done correctly the
        first time. Your best bet is get this current manager fired or transferred.
        The new manager will blame the old manager and then he will recommend a
        rewrite. He will attribute the success of the second go around (see Eric
        Hodges's email) to his expertise as a manager, you will rise far on his coat
        tails, some guys have all the luck.

        John A
      • David Brady
        I m an XP newbie, so can t state the official XP position. However, I suspect the official XP position would be, Well, that depends.... :-) I can imagine
        Message 3 of 5 , Apr 3 7:12 AM
        • 0 Attachment
          I'm an XP newbie, so can't state the official XP position. However, I
          suspect the official XP position would be, "Well, that depends...." :-) I
          can imagine cases where either solution would make more sense than the
          other.

          From my experience, you can get all kinds of political backing/favors in a
          company if you tell your manager, "Um, I think we can do something with the
          existing codebase."

          I admit I'm biased; I've never seen a rewrite succeed. (Pause for dramatic
          effect.) In three attempts at three different companies in ten years, every
          single rewrite attempt was canceled by management after an intolerably long
          period of non-visible results went by. Twice it was management's fault,
          once I think it was deserved (the team had a 9-month project cycle, and
          spent 6 months developing the BigDesignUpFront, then announced to mgmt that
          we would neet another 18 months to complete the project).

          So I've learned to go with code I already have. At least that way, my
          manager can go away reassured that he still has a product.

          -dB
          --
          David Brady
          dbrady@...
          Diagonally parked in a parallel universe


          > -----Original Message-----
          > From: Chris Bitmead [mailto:chrisb@...]
          > Sent: Sunday, April 02, 2000 7:39 PM
          > To: extremeprogramming@...
          > Subject: [XP] fix or rewrite?
          >
          >
          >
          > What do people think? If a project has been pretty soundly bodged, but
          > somehow has been able to be patched together with duct-tape
          > and chicken
          > wire, is there any hope of incrementally fixing it to come up with
          > something of quality, or should it always be thrown out and re-done?
          >
          > Companies never like to admit they screwed up and have blown their $$.
          > On the other hand I usually think a project that has gone way
          > off-course
          > is unrecoverable, or at least uneconomic to recover. But then
          > programmers like new code, so maybe I'm biased. What do others think?
          >
          > --------------------------------------------------------------
          > ----------
          > To Post a message, send it to: extremeprogramming@...
          > To Unsubscribe, send a blank message to:
          > extremeprogramming-unsubscribe@...
          > Ad-free courtesy of objectmentor.com
          >
          > --------------------------------------------------------------
          > ----------
          > -- Easily schedule meetings and events using the group calendar!
          > -- http://www.egroups.com/cal?listname=extremeprogramming&m=1
          >
        • Chris Bitmead
          ... I admit I m biased; I ve never seen hacking on a truely bad code base produce a result in a reasonable time period. I always see spending time on bug after
          Message 4 of 5 , Apr 3 5:36 PM
          • 0 Attachment
            David Brady wrote:
            >
            > I'm an XP newbie, so can't state the official XP position. However, I
            > suspect the official XP position would be, "Well, that depends...." :-) I
            > can imagine cases where either solution would make more sense than the

            > I admit I'm biased; I've never seen a rewrite succeed. (Pause for dramatic
            > effect.) In three attempts at three different companies in ten years, every
            > single rewrite attempt was canceled by management after an intolerably long
            > period of non-visible results went by.

            I admit I'm biased; I've never seen hacking on a truely bad code base
            produce a result in a reasonable time period. I always see spending
            time on bug after bug after bug. After working for about 12 months like
            this you usually seem no closer to having something good, wheres
            the whole thing seems no harder to rewrite in 12 months.
          • Steve Molitor
            ... But how does one define doesn t work? If the code is in production, but with lots of bugs, does that mean it s working? -- Steve Molitor
            Message 5 of 5 , Apr 4 7:35 AM
            • 0 Attachment
              "Kent Beck" <kentbeck@...> writes:

              > If you have crappy code that doesn't work, flush it. The bigger the pile,
              > the faster you should flush.

              But how does one define "doesn't work?" If the code is in production,
              but with lots of bugs, does that mean it's working?

              --
              Steve Molitor
              smolitor@...
              "Emacs is the Computer"
            Your message has been successfully submitted and would be delivered to recipients shortly.