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

50224Re: [scrumdevelopment] Re: Break from sprinting - a strategy sprint

Expand Messages
  • Ron Jeffries
    Feb 2, 2011
    • 0 Attachment
      Hello, Roy. On Wednesday, February 2, 2011, at 6:34:41 PM, you
      wrote:

      > I have always had the impression that trying to 'update' a legacy
      > system, in the way that I think you are indicating, can turn into
      > a quick sand swamp of frustration and fire fighting (excuse the mixed metaphors).
      >
      > I honestly think that it is usually better to use the legacy
      > system as a 'prototype' for the new system, and, instead of trying
      > to patch the old system, you develop a new system in parallel.
      >
      > At least, this is the theory of the thing, and is probably a
      > difficult game to sell. But I have really had a lot of experience
      > seeing people trying to 'fix it' when, if they scratched the old
      > and developed the new, with the same intention that the old was
      > developed for, it would save a lot of time.

      Have you ever been engaged in a project to rewrite a legacy system?
      I'd like to hear about the results: your blase presentation of this
      idea tells me that if you've done it, you must know some secrets
      that I do not.

      I have been involved in several conversions, and I would prefer
      never to do it again, even with an Agile approach (but more about
      what I'd do if I had to below). What happens is:

      0. All the following criteria are absolute and highest priority.
      1. We need all the functionality of the old system.
      2. It has to be completely compatible with the old system.
      3. All the bugs have to be fixed.
      4. There are some bugs which, if fixed, would break compatibility.
      5. We have many new features that are absolutely critical.
      6. It has to be much easier to use and better looking, while
      remaining completely compatible.
      7. Conversion from the old system has to be trivially easy,
      absolutely seamless, and perfect.
      8. The situation is time critical. We are already late.
      9. We will be adding a few new important features to the
      old system. We're sure that you won't have any trouble adding
      them to yours. Be sure to watch version reports to find out
      what they are.

      After that, it starts to get really ugly. Every project of this kind
      that I've been involved in turned into a death march where most of
      us would have preferred actual death. Except for one: The Chrysler
      C3 project. It went really well except for being scrapped at the end
      despite that it was working fine.

      Now then. What would I do, faced with this opportunity?

      One possibility: Refactor the old system into a better system. This
      is not easy, as it requires great refactoring skill. However, if you
      do not have great refactoring skill, where do you get off telling us
      you are qualified to rewrite this giant steaming pile to make it
      better.

      Another possibility: Strangle the old app. Implement new
      functionality in a clean way, and eviscerate the old system one bit
      of functionality at a time, calling out to the new. This might
      continue forever; it might be that we'd call it good enough and
      stop; it might be that we would use the momentum of the new stuff
      working to continue forward.

      Yet another possibility: Build a new system as if we were one of our
      competitors. The new system is intended to be so good and so full of
      new capability that it wipes out the market for the old one, without
      ever needing to match it feces for feces.

      Absent any of those possibilities, I'd consider finding gainful
      employment in food services.

      Ron Jeffries
      www.XProgramming.com
      It is a bad plan that admits of no modifications. -- Publius Syrus (ca. 42 BCE)
    • Show all 19 messages in this topic