I've been involved in the assessing whether a number of our systems need to be rewritten from the ground up or if they should be partially rewritten, or if they should just continue as is with patches on top.
In order to better assess the situation I was wondering what questions I should be asking myself and others to help determine the appropriate action to take?
I'd recommend you read Things You Should Never Do, Part I. He makes a strong case for not redeveloping.
Money quote:
It's important to remember that when you start from scratch there is absolutely no reason to believe that you are going to do a better job than you did the first time. First of all, you probably don't even have the same programming team that worked on version one, so you don't actually have "more experience". You're just going to make most of the old mistakes again, and introduce some new problems that weren't in the original version.
Perhaps you should ask yourself if you know the system well enough to fix the problems without re-writing it. If you don't, it might be safe to say you don't know the system well enough to redevelop it from the ground up.
in the following order:
Finally you want to achieve something whenever you rewrite a system from the scratch. You should ask yourself what do you want to achieve? Do you want to:
You could do a break-even analysis to see when your new system starts to pay out. In my opinion you should be able to reduce rewriting the system to costs and be able to see that a new one costs less than the old.
In general, I've found that re-writing code tends to be trouble (it is expensive, time-consuming, and involves a discovery phase that makes the first system look better).
That said, here are a few questions to ask:
Would core refactoring suffice? You'll know from evaluating the system whether or not the central issues go deeper than the code. If the issues are in the code base (rather than the technology itself), I prefer refactoring.
To what extent is the current system testable? Testability goes a long way toward extending the service life of any system module because testable code generally lends itself more readily to extension and maintainability. This relates to #1 as well.
Lastly, would the value provided from a re-write justify the effort. This is a business question, certainly, but one that the developer can and should help make.
In most cases I've encountered, the answer was no.
How long will you be unable to deliver? How much time By what factor have you underestimated previous projects? How much time can you afford in the worst case?
How much manpower currently goes into maintaining the existing system(s)? Do you have this manpower available in addition to the people developing the new system?
How can you make sure you don't recreate the same system with the same problems? Avoiding the obvious architecture faults is usually not enough.
Will you be able to compete/survive if you have no ressources to improve the current system?
Even if "Refactor and Repair" means, on the long run, replacing most of the existing system, it means putting all ressources into ONE system, rather than two.
I suggest that you need a context for the discussion, and the best one I'm familiar with is found in Martin Fowler's "Refactoring" book. To me the question really is "Is this application refactorable?"
The first specific guideline would be "Is it written using good OO design principles?" If not, usually you need to either put it on life support, and/or start over. If it is, then the book will provide lots of help; and in my experience there's good reason for hope.