Evolution or Revolution to fix poorly written code.

Question

I've done some work for a personal project of mine, and now I understand why people tell us to plan out all our interfaces and design before coding. I've got some good classes and already have some working code, but all in all the the organization (architecture) is somewhat of a mess, and I'm already saying "If I did it again, I would do it like this...". The question is, should I sketch out a plan of how I want my code to look, and refactor the existing code to the new model, or if I should take what works great, and write all new code for the deficient parts (basically starting from scratch with a fair amount of copy and paste from this project).

I've got git history I'm not sure I want to lose, but the task of slowly rewriting everything seems daunting. So the question I'm asking is: when refactoring a young project, should one use evolution or revolution to get it right the second time?

Answer 1

Refactor the old code (evolution). Rewriting code always introduces problems that you didn't think of. I am sure there have been updates to the existing code, and a lot of those updates are bug fixes enhancements etc. You may not know why you made a change at the time, but you needed to, and rewriting the code could remove that needed change.

Taking small steps also helps you avoid the "Oh 'expletive'" scenario where you try and make some massive change and encounter a situation where it doesn't behave they way you expect it to. With evolution, you can back out a change and still have a working system since the architecture is somewhat finalized.

Answer 2

Normally, I use evolution, but in big steps, so a little of both.

Answer 3

Depends on your situation - if you have the time to re-write... and less obviously re-TEST everything.... blow it away and start fresh. But be honest with yourself about what that time is going to look like.

Evolution works a lot better typically - because time is money, and starting from scratch can represent a huge investment....

Another bit that a lot of people don't get - evolution can actually work VERY well - it just takes more thought... you have to figure out where how to modularize existing things - but typically it's very possible - just extra time at the whiteboard.

Answer 4

How do you fix a big, crappy project? Well, how do you clean out the Augean Stables...

Stable-cleaning techniques:

1. If you're Hercules, you do it all at once in a big splashy, er, flashy way.
2. If you're not Hercules, you grab a shovel, and start slowly improving things one corner at a time.

The trick is to recognize ahead of time whether you have the strength and ability to tackle a re-write. Underestimate yourself, and you'll waste a lot of time wading through manure. Overestimate, and you'll just make a bigger mess...

Answer 5

Work out how you'd really want to do this. Make a diagram that you put on the wall, try to think of all the details.

When you do make changes, try to find out how each change can bring you closer to the end goal. If you have this goal in your mind while making changes, you can both code and test stuff that is consistent with where you want to go. Often I find that I can introduce some of the less radical (but necessary) changes and still cash in on benefits.

So I'm advocating evolutionary but with a clear perspective of where you (think) you want to go. You're going to end up somewhere else anyway.

Answer 6

You need to compare the task of slowly rewriting everything (which you may be mentally exaggerating) to the task of attempting to swiftly rewrite everything (which you're probably seriously underestimating). Don't underestimate the value of keeping working code, which you get with gradual refactoring.

Since you don't describe your platform, I don't know what software is available for refactoring support. There's plenty for Java, for example, but darn little for C++.

Knowing almost nothing about you and your project, I'd suggest refactoring in a more evolutionary manner, and doing it fairly quickly before you get disgusted with the old code or write too much new code that relies on the bad old things. You may well find code that's too ugly to live and needs a rewrite; in that case, go ahead.

Answer 7

The problem with a revolution that it will take a long time, during which no value is produced to the end users. With incremental changes (evolution) it's possible to improve the system and keep it running at all times.

Uncle Bob's thoughts about the matter: http://blog.objectmentor.com/articles/2009/01/09/the-big-redesign-in-the-sky

Answer 8

I think it depends on several factors:

1. Do you have unit tests? This argues for refactoring.
2. How long did it take originally? A day or two argues for rewrite, a week or two to refactoring.
3. Do you rely on it daily -- do you need to keep it running? If yes, refactor. If not, rewrite.
4. Just how bad is it? If really bad, rewrite it.

In all cases, know where you're headed before you start!

(Personally I don't buy the argument that you should never rewrite. I also don't buy the argument that well-crafted systems can arise solely out of refactoring...)

Answer 9

In the (paraphrased) words of Fred Brooks, "Plan to throw the first one away". If you haven't planned to do so, you will eventually junk it anyway. The only question is, after how much work?