Making big changes incrementally

Question

Currently working on a complete front-end and back-end overhaul of our webapp. We did this because a lot of changes needed to be made to the database schema as well as the user experience.

Now we are almost done with the overhaul and I'm thinking if we could have taken a more incremental approach? We started a new codeline for this overhaul and now we have to figure out a good data migration plan to make sure the old data is transferred over to the new schema properly.

We made the decision to do a separate codeline because we thought that if we did incremental changes to the schema, there would be more downtime to the site. A separate development cycle for it would reduce that downtime to the final day when we do the data migration. And of course that carries more risk.

What are some good approaches to this problem for the future if we ever need to do another major overhaul? Incremental approach would be desirable.

Answer 1

You are right to fear the complete rewrite, nothing is ever scarier in the world of refactoring. There are many strategies for breaking down the rewrite into digestible chunks, and it depends on what's wrong with the code base to begin with. Was it spaghetti? Was it inherently unstable? Or, based on deprecated services?

Without understanding more about your code base, I can only offer something generic and hopefully it helps in some way. Some things to try, maybe, assuming the problem is poorly structured spaghetti.

1. Start decoupling everything. Try to eradicate state and dependencies, piece by piece. This can almost always be done incrementally. Also, break apart the monster functions and modules.

2. As things get decoupled, sic the unit tests on them. You need stability throughout the refactor, and that should be your baseline.

3. You now have lots of little, independent things. Look at the patterns and start to organize and recombine.

4. As you do this, it may help to adopt an agile dev approach.

At the end of all this, you may not have the Ivory Tower that proponents of the rewrite might hope for, but you'll have tangible improvements that will likely eliminate the need for a complete rewrite.

Answer 2

Small is always better than big!

An incremental approach, dividing the upgrade into several small releases is usually the best approach, though its a hard sell to management.

It sound like splitting your project up into:--

• presentation code updates to enable the fancy stuff, plus an implementation of some of the simpler user experience enhancements (i.e those that don't depend on schema changes).
• schema upgrade enabling release. i.e. upgrade the schem, plus the technical changes in the programs to handle the new schem, but only business logic changes absolutly required by the new schema.
• changes to your business logic to take full advantage of the new schema.
• finally, the full enhanced user experience.

I find separating releases into technical/enabling releases, followed by a separate release for business logic changes, keeps each release controlled, focused and as small as possible. Resulting in quicker development and fewer bugs.

Answer 3

Start small. I would suggest an incremental approach with the following approach:

• Pick a part of the system, preferrably the one that is in most need of refactoring.
• Get this part of the system under test if possible. If not, do it after depencies have been broken.
• Start refactoring this part of the system by breaking dependencies.
• Verify that your changes work as intended through the tests.
• Repeat.

Michael Feathers has a great book about this called Working Effectively With Legacy Code. I recommend it. For further assistance when it comes to breaking dependencies in code, try looking into the Mikado Method.