Darren Hobbs writes that almost no rewrites have any technical merit. This is often true, but not always. There are many working systems out there which are stable but just too hard to change — which makes them a threat to the survival of the business. All those other reasons that Darren mentions, such as cost and politics, might well be sufficient justification for change from the business' point of view. Finally, it's worth remembering that often what keeps these rewrite candidates alive is an unholy collection of scripts, utilities, and other systems to manage their relationship with the rest of the world.
One way to think about a rewrite is that the interest payments on a large Technical Debt are about to drive the system into Technical Bankruptcy. At this point, the business has to do something to cut the payments: either let it fail and start again, or spend some real money making it better. True, many organisations appear to choose a technical loan shark to help them out, probably the same ones who got them into the mess, but it doesn't have to be that way. A "good" rewrite is a chance to revisit a chunk of functionality that has been proven useful and is now better understood. That's partly why Alan Kay talked about burning the diskpacks.
OK, so I can hope...
Posted by stevef at March 13, 2005 9:35 PM