In software world we call this speculative generality or YAGNI or over engineering.

IMHO we should not be afraid to throw parts of your system out every 6-8 months and rebuild it. Speed and Simplicity trumps everything! Also in 6-8 months, new technology, your improved experience, better clarity, etc. will help you design a better solution than what you can design today.

Just to be clear, I’m not suggesting that we do a sloppy job and rewrite the system because of sloppiness. I’m recommending, let’s solve today’s problem in the simplest, cleanest and most effective/efficient way. Let’s not pretend to know the future and build things based on that, because none of us know what the future looks like. Best we can do is guess the future, and we humans are not very good at it.

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.