We are asked the question about retrofitting single threaded or single tasking applications allot. Why? If it's not broke, then leave the poor application alone -- right?

Almost invariably come the appeals to better customer service. We want to make the application faster to better serve the customer, so we thought now would be a good time to update the software and take advantage of the new machines we just purchased. Again we usually suggest that they make sure their database servers, web servers, etc., are properly retuned for the new machines. Try to get speedup without terrifying the application. Retrofitting an application that is already working to include multithreading or multiprocessing so that you can take advantage of new multiprocessor capabilities is a noble goal (for some reason Don Quixote comes to mind) but will the benefits of the speedup achieved (if any is achieved) outweigh the costs of the redesign, the introduction of a entirely new set of testing techniques, debugging techniques and test sets? Is the speedup worth the additional effort and cost that will be expended every time the application needs modification?

Retrofitting (a.k.a paradigm shifting) the single-threaded application comes at a cost at several layers of the Software Development Life Cycle (SDLC) and the Software Maintenance Life Cycle (SMLC). Does the cost-benefit of the speedup of the application justify the new SDLC and SMLC costs? If the speed up benefits truly outweigh the cost to get the speedup then, don't cut corners on the redesign. One of the first things we do is we get a helicopter's view of the application's actual architecture. Not the pristine architecture that the outdated documentation describes, but the actual living breathing architecture of the application as it now exists. Are we dealing with hybrid peer-to-peer with a little client-server thrown in for good measure? Or is it some hodge-podge of web services three-tier with mobile access thrown in or what?

Ultimately, we're going to move this whole thing to formal models and formal languages for the redesign. But before we can do the paradigm shift, we have to know precisely what the running/executing paradigm is. If it is truly worth moving to the new world, then let's do it right. We'll be back...