50224Re: [scrumdevelopment] Re: Break from sprinting - a strategy sprint
- Feb 2, 2011Hello, Roy. On Wednesday, February 2, 2011, at 6:34:41 PM, you
> I have always had the impression that trying to 'update' a legacyHave you ever been engaged in a project to rewrite a legacy system?
> 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.
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
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.
It is a bad plan that admits of no modifications. -- Publius Syrus (ca. 42 BCE)
- << Previous post in topic Next post in topic >>