"The code is too messy, it needs to be rewritten"  
How many of us have heard of (or said) the above statement? It is the typical statement given by most developers when assigned to maintain a piece of code developed by other developers who probably had left the company and in no way contactable (Or even if they are contactable, they will most likely have forgotten what they wrote).  
 
Most managers find it difficult to understand why code needs to be rewitten - afterall, a lot of time, effort and money have already been invested. Also it does not guarantee that after the rewrite, another developer assigned to maintain the code later will ask for another rewrite.  
 
Most developers find it frustrating to maintain other people's code because they have no control over it when there is a need for change. Prolong maintenance work can also retard a developer's creativity. Developers with weak tolerance will just move on to other jobs (and another developer will pick up the vicious cycle).  
 
Rewriting gives the developer better control over the code and allows them to handle change requests and enhancements better. Sometimes, developers silently rewrite parts of the code without informing their managers. With proper project monitoring and communication with the customer, a rewrite effort can result in faster delivery (or project recovery).  
 
"Tell developers what you want and let them work on it"  
I believe developers should be given the freedom to work on their technical solutions in order to fulfil the project goals or deliverables (as long as it is within scope). If codes are not maintainable to the developer, it is best to let them rewrite it because ultimately, they are doing the work. This is exactly like telling the mechanic what is wrong with your car and let him fix it.  
 
Software development is quite different from manufacturing. In manufacturing, we can always replace floor workers in an assembly line and they will still be able to produce the line items (i.e. television) on time. Every task is a step in a blueprint and everyone assembles the item in an identical manner.  
 
However in software development, no two developers can develop a piece of software with the same set of specifications in an identical manner. The reason is software development is more or less equilvalent to art. One artist may start off with a stroke to draw a river but the next artist who inherits the incomplete art may spend tremendous time trying to figure what the stroke represents.  
 
So, do we authorize a rewrite every time a developer comes asking for it? It really depends. It takes a lot of software development experience in order to spot whether a piece of code has no hope. We also need to look at other constraints. There are greater implications when rewriting code on a different platform.  
 
Sometimes we may be faced with a failing project, where the project has overshot by a year, changed hands many times, missing documentation and the customer is furious but yet the management is hanging on to it. In such circumstances, most project managers will try to do keep as much codes as possible in order not to upset the situation.  
 
However, in my years of experience in software development, the best way is to start from a clean sheet. Study the logic, understand the rules and start from ground-up. It is always faster this way than to go through tens-of-thousands lines of spaghetti code.  
 
to be continued ...