A lot of developer have a tendency to suggest rewriting legacy code instead of refactoring. Personally I don’t think one approach is better than the other. Following are the issues/issues one needs to consider with each:

Rewrite:

• Difficultly in coming up with Cost and Time estimate. (Its best to pull some numbers off the hat)
• What if new bugs are introduced during rewrite?
• Similarly how do you avoid unintentional behavioral changes?
• What is the guarantee that you won’t end up with the same problems?
• How do you get Management buy-in? Let’s say even if you get Management buy-in, how do you motivate developers to rewrite existing apps?
• While rewriting, we’ll certainly introduce new technologies. How do you deal with problems introduced by new technology?
• How to handle change requests during rewrite?
• How to avoid not over engineering the solution?
• How do you deal with various Political Issues around technology, tools, team, etc.?
• How do you avoid Resume Driven Development?

Refactor:

• How do you deal with Refactor-Test Dilemma (Egg and Chicken problem) ?
• How do you motivate the existing team to continue and refactor code?
• How do you effectively identify the inflection point?
• How to avoid big changes (in the name of refactoring) instead of baby steps?
• It takes quite a lot of time and effort to understand legacy code
• Even while refactoring developers might have a tendency to over engineer (esp. coz most developers conclude that the original developers did not think well and build an extendable solution)
• To Refactor effectively it certainly need developers with higher skill-set. Can you find them?
• Many times you’ll run into difficultly in breaking dependencies. How would you deal with it?

In my experience a thin-sliced hybrid approach seems to work the best both from technical and business point of view. In a subsequent blog I’ll explain what I mean by thin-sliced hybrid approach.

If you’ve inherited a Legacy Project (project without any tests) and say you want to enhance an existing feature, where do you start?

In such situations, I find myself building some form of workflow tests (scaffolding). I start off using a record and play back testing tool to record couple of scenarios for the feature, I want to enhance. Most often, I would take the recorded tests and covert them into a re-entrant, independent scripts. So that I can execute them over and over again, without needing manual intervention. Basically this would mean, automating the set up and tear down of the application’s external dependencies like data-stores, email servers, etc correctly. This should not take more than a couple of hours to configure.

This helps me build the initially safety net to start off. This also gives me a decent understanding of how the feature works. Now I can go inside the code, change something really small and see what impact it has on my tests. Some times I tweak my test to see what impact it has on the feature. Basically I’m using this test as a probe to gain deeper understanding of the feature’s functionality.

Doing this give me some confidence to jump in and start refactoring the code, so that I can create an inflection point, break dependencies and start writing unit tests around the core of my feature. In couple of hours, I should be able to build a solid safety net, around my feature using unit tests and/or business logic acceptance tests.

At this point, I almost always, go and delete the initial workflow test that I had built. This is the reason, I call this approach as the scaffolding technique.

• Build some initial workflow tests to help you get in there,
• Make the necessary code/config changes to write direct tests
• Gradually build a solid safety net around the feature
• The scaffolding (initial workflow tests) did its job, now its time to throw them away