Rewrite v/s Refactor Dilemma
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.
