| Wow - I just want to express some gratitude for the thoughtful response here. You've captured the essence -- although we have solutions for when the impulse to rewrite an application occurs, we don't have solutions that don't bring their own problems. Further, the natural human expectation for the software engineer to be like Chuck Norris, who can Fix Everything Without Changing Anything, needs to be considered and managed. The opposite - where, as someone else termed it - the new version is based on a grab-bag/wishlist of everyone's hopes and dreams, generally doesn't work out either. The true path does seem to be: * setup integration tests that validate WHAT the system does (blackbox), rather than HOW the system works (vs whitebox). * build the new system modularly, offloading one part of the old system's work onto the new system, one part at a time. * keep the new and old system synchronized, using eventing/message-queues/etc (this is going to be difficult) * continue replacing the old parts of the system with their new replacements until the old system no longer exists * Now you've created the old system again, but the code and architecture are clean and capable of the changes that were not possible before * Move forward confidently adding new features and capabilities to your new system which does not suffer from the problems of the old system. |