3 ms·

Lesson 1: Don't ever attempt a big rewrite?

antonpirker 12y ago
Sure you can attempt a rewrite! But you must make sure that you know what are getting into. It is not an easy thing to do, but once the rewrite is done your live gets way better :)
- arethuza 12y ago
  Having had rewrites of large projects go spectacularly well and also spectacularly badly, I suspect one factor to be mindful about is if the rewrite facilitates the "second-system effect" - I've had that happen where the rewrite of a messy but successful suddenly allows the introduction of lots of cool features you've wanted to add for ages and you actually end up with a "simplified" system that is actually a lot more complex than the original. NB I've only had one project go badly wrong that way and I guess it was a useful learning experience :-)
chriswarbo 12y ago
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).

Sure you can attempt a rewrite! But you must make sure that you know what are getting into. It is not an easy thing to do, but once the rewrite is done your live gets way better :)

arethuza 12y ago
Having had rewrites of large projects go spectacularly well and also spectacularly badly, I suspect one factor to be mindful about is if the rewrite facilitates the "second-system effect" - I've had that happen where the rewrite of a messy but successful suddenly allows the introduction of lots of cool features you've wanted to add for ages and you actually end up with a "simplified" system that is actually a lot more complex than the original. NB I've only had one project go badly wrong that way and I guess it was a useful learning experience :-)

chriswarbo 12y ago

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).