Refactor or re-write?

[Uhfgood]

I'm kind of curious as to what you'd choose, one or the other, and why?

Lately i'm finding that if I keep re-writing a piece of code, eventually it does what I want, and does it well, and the code is clean (well as I can figure)... Re-factoring ends up taking some extra time, keeping the code clean. I just figure it makes me a better programmer if I actually rewrite it rather than just cleaning it up.

Your thoughts?

Keith

[ggambett]

I just figure it makes me a better programmer if I actually rewrite it rather than just cleaning it up.

And do you care about that? I don't care that much. If you have a piece of code that has been worked and being debugged for years, rewritting it is quite dangerous... refactor in small steps and test test test after each step. Besides, after a lot of refactoring, my code ends up looking as if it was rewritten, and most often, that's the case.

[EpicBoy]

I just figure it makes me a better programmer if I actually rewrite it rather than just cleaning it up.

This gets back to the "illusion of progress" effect discussed a while back. Rewriting the code may make you feel good and pump you up as a programmer, but it is helping your project get out the door? If the answer is "no", it's the wrong choice.

[Bluecat]

It really depends on what you are trying to achieve.

If you are just adding features to a program, then refactoring would be my choice. If you need something very different from the original software, then a rewrite might be the way to go. Having said that, sometimes both can be useful. If the software needed a complete rewrite, some parts of it might be better factored out of the main body and put into a library. Especially if they are already clean, and won't change from one program to the next.

In the end, the question you need to ask, is what will save you the most time and effort?

[GBGames]

If you are fairly disciplined in changes you make, then refactoring would probably be quicker for you.

Of course, if your programming style is ad-hoc rather than more disciplined, rewriting will definitely be much easier than trying to make changes to a mound of code and trying to figure out what you broke.

Rewrites help when the code you already wrote is doing the wrong thing or is not very easy to understand. I've found in the past that pruning and cleaning code sometimes introduces more bugs requiring more pruning and cleaning.

[Aggrav8d]

5.2

A manager asked a programmer how long it would take him to finish the program on which he was working. "It will be finished tomorrow,'' the programmer promptly replied.

"I think you are being unrealistic,'' said the manager. "Truthfully, how long will it take?''

The programmer thought for a moment. "I have some features that I wish to add. This will take at least two weeks,'' he finally said.

"Even that is too much to expect,'' insisted the manager, "I will be satisfied if you simply tell me when the program is complete.''

The programmer agreed to this.

Several years later, the manager retired. On the way to his retirement luncheon, he discovered the programmer asleep at his terminal. He had been programming all night.

-- the Tao of Programming

[GBGames]

Ah, the Tao. I love those stories. B-)

[oNyx]

It depends on how bad the code actually is and if it's working correctly. Generally it's about how sure I am that it works correctly. For example there is a somewhat cryptic algorithm, which is about 300 lines and worked 100% correctly - I won't touch it. But if it's looking odd and works in 99% of the cases, I'll throw it away, because I'll be done faster if I just write it anew in a clean and simple way.

There are always some parts of code, which just look messy and sometimes there is nothing you could do about that. Well, as usual - it's the result which counts.

[Ronkes]

In my personal experience you should always prefer refactoring to rewriting. With rewrites you have a very high risk of throwing previous experience and bugfixes away. You'll probably solve the bug that got you to rewrite your code, but you'll introduce a couple of new ones. I've been burned by rewrites more than once.

Refactoring puts more emphasis on having code that works, since a single refactoring should leave the proper operation of your program intact. Refactoring usually involves a lot of very small changes. Since you have to test each of these changes seperately to see if your program still works as it should, unit testing or another form of automated testing is invaluable while refactoring.

[EpicBoy]

In my personal experience you should always prefer refactoring to rewriting. With rewrites you have a very high risk of throwing previous experience and bugfixes away. You'll probably solve the bug that got you to rewrite your code, but you'll introduce a couple of new ones. I've been burned by rewrites more than once.

Me too. I've been rewriting code and came across something in the old code that looks weird ... alarms go off in my head, but I rewrite it the "right way" and move on. Unsurprisingly, the next day I get bug reports about something not working right. Inevitably there is code somewhere else in the system that was relying on that functions weird behavior. Generally, the older a code base is, the scarier it is to rewrite things - as code matures and other code comes to leverage or work around existing bugs, fixing those bugs becomes more dangerous than just leaving them in place.

[Aggrav8d]

It's probably going to sound very arrogant of me, but:
Refactoring implies that the code only has a small design problem, whereas rewriting implies that the code has an irreconcilable design problem. I'm sure we've all rewritten and refactored. I just hope others will agree with me that if you take the time to plan it right at the beginning you shouldn't have to refactor much later.

[EpicBoy]

I just hope others will agree with me that if you take the time to plan it right at the beginning you shouldn't have to refactor much later.

If I was in school, I would agree with you. However, having worked many years in the real world, I don't really believe this is realistic.

[Mark Fassett]

I agree with EpicBoy. In any project of any significance, no matter how much you plan, there are going to be things that just didn't work as planned, or that weren't planned for, and refactoring will be a necessity.

Rewriting is only worthwhile when:

A) The code is so horribly buggy that you couldn't possibly create more bugs than already exist,
B) You wrote the code recently, and thought of a much better design in the meantime AND you don't have anything better to do
C) The code sort of does what you need it to do, but not really, and you need more or different functionality.

[Sybixsus]

I just figure it makes me a better programmer if I actually rewrite it rather than just cleaning it up.

I absolutely agree, and if I didn't have to eat and pay the bills, and it was all about an intellectual exercise, I would do that. But unfortunately, the people who rewrite every time their code gets a bit messy don't finish many projects, whereas the people who cope with the errors and fix them, while still picking up tips to improve for the next project are the ones that finish projects and pay bills. If I was independently wealthy, I'd definitely go with the rewrite, but I'm not.

[Uhfgood]

Okay granted, rewriting takes more time. I guess I wasn't really clear on the type of code I was talking about. Really i'm talking about something that just isn't working in the first place, or is not doing what you want, but then I guess you don't need to refactor something that's working. Of course there is stuff i'm working on and it's pretty messy, although it works ok. I feel I want to organize it better, and write it better, so i'm considering rewriting that. The only thing about this is that this is a copy paste job, because of the type of code it is, i'll pretty much end up copying from my old source code to write the new. So in essence it's like re-factoring.

Well again I guess I asked a stupid question, but that's just me.

Keith

[Ronkes]

Refactoring does not imply anything about the size of the problem, just that you try to solve it step-by-step. No amount of planning can prevent that you change your mind about a bit of code at some point. It's hard to make all architectural decisions beforehand. You don't always know whether you really need to create an abstract base class or not. If you integrate refactoring into your way of development, you can do what works at that very moment (even if it feels a bit funny) because you can always make a change - like extracting a base class - later.

Mind that I'm not talking about fixing bugs here; that's not refactoring. Nor is it rewriting. It's... well, bug-fixing.

Keith, if you plan to copy and paste a lot, that implies some of your code is fine. I think you're better of putting some automated tests in place and then refactor your existing code. Fixing your code's organization is easier to do with refactoring than with rewriting.

Also, I think this is a very insightful question, nothing stupid about it.

[Bluecat]

I recommend the book Refactoring by Martin Fowler. I think it's pretty much the seminal work on the subject.

[Coyote]

I'm sure we've all rewritten and refactored. I just hope others will agree with me that if you take the time to plan it right at the beginning you shouldn't have to refactor much later.

No plan survives contact with the enemy. Or the customer. Or the focus group. Or the programmer, once he's had a chance to take a step back and look at it with the advantage of hindsight.

Planning in software development is more like writing a script for a potential movie than writing a blueprint for an office building. Entire sections are going to get added, cut, or substantially modified later, assuming it's not one of those cases where the entire script gets thrown out and a new one (or three) written later that kinda-sorta uses the same characters and situations and vaguely resembles what you originally wrote.

I'm not saying that planning isn't important. Quite the contrary - you will be better prepared to deal with the changes if you plan well in the beginning. But thinking that it will protect you from having to make massive amounts of changes, rewrites, and refactoring is hopelessly idealistic.

On the original topic - it depends on the extent of the changes. If I'm really performing a massive overhaul on code, I tend to prefer a complete re-write. If I wrote the original code, I have the benefit of experience - which usually makes the re-write MUCH faster than the development of the original. And I usually write my code to be very modular and easy to replace. If it's someone else's code, I still prefer a rewrite, although I may cut & paste code from the original in the new version. I figure if I have to do a massive change to it, I may as well build it from the ground up so I know exactly how everything works and can more easily maintain it later.

If it's just a few changes, I'll go with a refactor. But the more extensive the refactor is, the more prone it becomes to yielding... unintended consequences. As EpicBoy described.

[Bluecat]

If it's just a few changes, I'll go with a refactor. But the more extensive the refactor is, the more prone it becomes to yielding... unintended consequences. As EpicBoy described.

Don't forget though, refactoring only aims to change the code... not change the functionality.

From Martin Fowlers website: Refactoring Homepage

Refactoring is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior. Its heart is a series of small behavior preserving transformations. Each transformation (called a 'refactoring') does little, but a sequence of transformations can produce a significant restructuring. Since each refactoring is small, it's less likely to go wrong. The system is also kept fully working after each small refactoring, reducing the chances that a system can get seriously broken during the restructuring.

The current philosophy for refactoring code, according to the agile programming crowd, is to write a (set of) unit test(s) for the code that you want to refactor. Do the refactoring, changing the tests if necessary, making sure the tests all pass. Then rinse and repeat as necessary.

[Kai Backman]

I have used both (and XP), and I think we all agree that a solid unit test framework helps a lot when refactoring. I find myself rewriting most often when I'm learning a new system, language, or paradigm. I'm currently in the process of rewriting my e-commerce site, a set of maybe 40 php files that I have been refactoring and improving during the last two years. I could probably have achieved this change with a refactor and feature add as well, but since I had more than two major paradigm shifts after I wrote the system, and neither of them has yet been incorporated due to lack of time, a rewrite is in order.

Sometimes you just need to start fresh, or throw a lot of stuff away. Intellectual excercise might also be beneficial for you business, in the very least, it is beneficial for you mind. Refactoring usually doesn't change paradigm easily, so you might end up creating the worlds cleanest batch processor, when everyone else does interactive (the must-have Brooks reference in any SE discussion.. )