Agile FAQs
  About   Slides   Home  

 
Managed Chaos
Naresh Jain's Random Thoughts on Software Development and Adventure Sports
     
`
 
RSS Feed
Recent Thoughts
Tags
Recent Comments

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.

  • http://blog.thecodewhisperer.com J. B. Rainsberger

    I call my approach “incremental rewrite”, which I guess is similar to your hybrid slice approach.

    I rewrite tiny parts of the legacy code using test-first programming. I leave behind a one-line delegate from the legacy code to the new code. As the new code gains critical mass, I round it out into modules that replaces larger parts of the legacy code. Over time, I migrate clients of the legacy code to use the new code. Eventually, the new strangles the old.

    I start by only rewriting/recovering/rescuing parts of the legacy code that I have to change to add a feature or fix a mistake.

    This approach seems to handle most of the issues you cite above.

  • http://twitter.com/xagile Adam Sroka

    I like the way Uncle Bob puts it. Full rewrites just lead to greater maintenance. Instead, we should strive to make small improvements wherever we find ourselves in the code.

    I think that the approach Joe describes is in that same spirit, and I don't object to the notion of being fairly proactive about it. Sometimes it is useful to duplicate old functionality that is written in an awkward way and then refactor to remove that duplication.

    I am curious to hear what “hybrid slices” are.

  • http://blog.thecodewhisperer.com J. B. Rainsberger

    I call my approach “incremental rewrite”, which I guess is similar to your hybrid slice approach.

    I rewrite tiny parts of the legacy code using test-first programming. I leave behind a one-line delegate from the legacy code to the new code. As the new code gains critical mass, I round it out into modules that replaces larger parts of the legacy code. Over time, I migrate clients of the legacy code to use the new code. Eventually, the new strangles the old.

    I start by only rewriting/recovering/rescuing parts of the legacy code that I have to change to add a feature or fix a mistake.

    This approach seems to handle most of the issues you cite above.

  • http://twitter.com/xagile Adam Sroka

    I like the way Uncle Bob puts it. Full rewrites just lead to greater maintenance. Instead, we should strive to make small improvements wherever we find ourselves in the code.

    I think that the approach Joe describes is in that same spirit, and I don't object to the notion of being fairly proactive about it. Sometimes it is useful to duplicate old functionality that is written in an awkward way and then refactor to remove that duplication.

    I am curious to hear what “hybrid slices” are.


    Licensed under
Creative Commons License