7 ms·

I agree; instead of doing big rewrites, do a bunch of small rewrites. Especially try to avoid "big bang" switchovers.

• twic 12y ago
  The OP's big rewrite was a lot of work. But I suspect that incrementally improving the legacy system to the point where it was as good as the new one would have been even more work. Incremental improvement is the right way to make small improvements. But a rewrite can be the right way to achieve root-and-branch reform.
  • chriswarbo 12y ago
    I wasn't advocating a gradual improvement of the old system. I meant identifying N particular tasks that need replacing, for example user accounts, content management, front-end, etc. Then for each one, isolating that part of the old system, eg. using a proxying layer. A replacement can then be built alongside, with the proxy sending all requests to both. Results can be compared, and differences treated as test failures. When the replacement is working, the proxy can be switched to serve the new system's responses, and once everything's settled down, the old system can be turned off. Once all of the new system is in place and replicating the behaviour of the old system, the rewrite is finished. New features and improvements can be worked on as normal, as a separate phase. What's more, we only need to feature-freeze the component that's being migrated, rather than the whole thing (as long as coding standards for new features enforce our newly-imposed compoentn isolation).