3 ms·

Refactoring vs. Rewrite

22 points by fogus 17y ago

einarvollset 17y ago
"I think we may expect something like.." This would have been a very interesting article if it was backed by actual data. It's not. Shame.
by 17y ago
I like the boy scout principle of "Leave the campground cleaner than you found it." http://www.moserware.com/2008/10/boy-scout-check-ins.html http://www.moserware.com/2008/10/boy-scout-check-ins.html With all the maintainers doing this at the code, database and design level you shouldn't need to do a rewrite. The problem is with 'immovable things' that necessarily accrete layer upon layer of work-arounds. If maintenance work allows 'immovable things' to persist in the application, at whatever level, the whole structure gradually degrades and a costly rewrite is eventually forced.
- barrkel 17y ago
  It's not nearly so simple in practice. If your codebase is old and large, and no one person knows it enough to change significant amounts of it, there are simply some fixes that you never have the time to risk.
  - by 17y ago
    Yes I agree if your 'immovable thing', for example the problem that would need a risky fix that nobody fully understands, can remain without much impact for the rest of the application's life. Sometimes I find I can move towards fixing something difficult in multiple steps as I apply successive features etc. I find that even just documenting the problem in the affected parts of the code can be a good first step. If something changes once it often changes again and I'll move it forward a bit more next time. My theory is that the movement is the important thing, not the arrival at some particular point.
Quarrelsome 17y ago
Wild speculation. Love it.
igrekel 17y ago
That is very short, the subject has been explored much more deeply in the past. I'd suggest Brian Foote's Big ball of mud where he talks about software going through phases of expansion and consolidation, he also discusses the total rewrite in much greater lengths. Although it too is lacks hard data and I find parts of the format and discourse annoying (can't exactly put my finger on why), I think it is still more interesting. http://www.laputan.org/mud/mud.html http://www.laputan.org/mud/mud.html
richardw 17y ago
Joel wrote an article back in 2000 on why you should never rewrite, mentioning Netscape. While I'm far less sure than he is about it (see below), there are some awesome points in there. http://www.joelonsoftware.com/articles/fog0000000069.html http://www.joelonsoftware.com/articles/fog0000000069.html While rewriting I've often been surprised how much I've had to re-discover and re-think, and how many mistakes I'll make second time around. On the other hand, on one occasion a rewrite saved the day because it pulled together 5 different apps in different languages in a new up-do-date platform. A few months of work and the sum was infinitely better than the whole and saved the business much more than it cost.
- jlouis 17y ago
  Interestingly however, much of the Linux kernel is based on the idea of pulling something off and then substituting it completely. For what it is worth, it seems to work for them.
- jcapote 17y ago
  I wish they had rewritten netscape, maybe firefox wouldn't be total garbage now. This advice, while great for some things, needs to be taken with a grain of salt. Sometimes, a full rewrite is the only option.
- firefalcon 17y ago
  There are some success scenarios for rewrite. For example, IE 4 was rewritten from the scratch. It became #1 browser. So it depends.
  - btilly 17y ago
    IE 4 was competing with NS 4, which also was largely rewritten. That leveled the playing field quite a bit. (Particularly since the NS rewrite introduced a lot of problems.)
- btilly 17y ago
  On the flip side during an extended major refactor your code looks like a construction site. You have some stuff that has been rewritten, some that hasn't, and no consistency. Then during the refactor people will rethink how they want it written, and you get more code styles. Frequently the dust and mess gets so discouraging that people start being driven away. And then the rewriting effort peters out and people just get used to living in a half-demolished house. The moral? Keep refactors small. If you want to do a major redesign, I would suggest rewriting a small prototype of a piece of it. If the prototype goes well then expand it until it can replace the previous system. (I've seen this prototype approach succeed several times. I haven't seen such good results with major refactors, or the "Let's rewrite from scratch!" approach.)
zyb09 17y ago
Now I'm the middle of rewriting a good-sized software system. The reason for this is, we had to a add a completely new security level on top of our data (user accounts, groups, individual column access). There's just no way we could've refactored our already tucked-together legacy code. This thing was passed along 4 different developers, each constantly adding new features and I'm surprised it hasn't exploded yet.We're getting calls every day cause something broke again. So yea sometimes rewrite definitively makes sense and I'm sure our customers will love it.

22 points by fogus 17y ago

"I think we may expect something like.." This would have been a very interesting article if it was backed by actual data. It's not. Shame.

by 17y ago

I like the boy scout principle of "Leave the campground cleaner than you found it." http://www.moserware.com/2008/10/boy-scout-check-ins.html http://www.moserware.com/2008/10/boy-scout-check-ins.html With all the maintainers doing this at the code, database and design level you shouldn't need to do a rewrite. The problem is with 'immovable things' that necessarily accrete layer upon layer of work-arounds. If maintenance work allows 'immovable things' to persist in the application, at whatever level, the whole structure gradually degrades and a costly rewrite is eventually forced.

barrkel 17y ago
It's not nearly so simple in practice. If your codebase is old and large, and no one person knows it enough to change significant amounts of it, there are simply some fixes that you never have the time to risk.
- by 17y ago
  Yes I agree if your 'immovable thing', for example the problem that would need a risky fix that nobody fully understands, can remain without much impact for the rest of the application's life. Sometimes I find I can move towards fixing something difficult in multiple steps as I apply successive features etc. I find that even just documenting the problem in the affected parts of the code can be a good first step. If something changes once it often changes again and I'll move it forward a bit more next time. My theory is that the movement is the important thing, not the arrival at some particular point.

Quarrelsome 17y ago

Wild speculation. Love it.

igrekel 17y ago

That is very short, the subject has been explored much more deeply in the past. I'd suggest Brian Foote's Big ball of mud where he talks about software going through phases of expansion and consolidation, he also discusses the total rewrite in much greater lengths. Although it too is lacks hard data and I find parts of the format and discourse annoying (can't exactly put my finger on why), I think it is still more interesting. http://www.laputan.org/mud/mud.html http://www.laputan.org/mud/mud.html

richardw 17y ago

Joel wrote an article back in 2000 on why you should never rewrite, mentioning Netscape. While I'm far less sure than he is about it (see below), there are some awesome points in there. http://www.joelonsoftware.com/articles/fog0000000069.html http://www.joelonsoftware.com/articles/fog0000000069.html While rewriting I've often been surprised how much I've had to re-discover and re-think, and how many mistakes I'll make second time around. On the other hand, on one occasion a rewrite saved the day because it pulled together 5 different apps in different languages in a new up-do-date platform. A few months of work and the sum was infinitely better than the whole and saved the business much more than it cost.

jlouis 17y ago
Interestingly however, much of the Linux kernel is based on the idea of pulling something off and then substituting it completely. For what it is worth, it seems to work for them.
jcapote 17y ago
I wish they had rewritten netscape, maybe firefox wouldn't be total garbage now. This advice, while great for some things, needs to be taken with a grain of salt. Sometimes, a full rewrite is the only option.
firefalcon 17y ago
There are some success scenarios for rewrite. For example, IE 4 was rewritten from the scratch. It became #1 browser. So it depends.
- btilly 17y ago
  IE 4 was competing with NS 4, which also was largely rewritten. That leveled the playing field quite a bit. (Particularly since the NS rewrite introduced a lot of problems.)
btilly 17y ago
On the flip side during an extended major refactor your code looks like a construction site. You have some stuff that has been rewritten, some that hasn't, and no consistency. Then during the refactor people will rethink how they want it written, and you get more code styles. Frequently the dust and mess gets so discouraging that people start being driven away. And then the rewriting effort peters out and people just get used to living in a half-demolished house. The moral? Keep refactors small. If you want to do a major redesign, I would suggest rewriting a small prototype of a piece of it. If the prototype goes well then expand it until it can replace the previous system. (I've seen this prototype approach succeed several times. I haven't seen such good results with major refactors, or the "Let's rewrite from scratch!" approach.)

zyb09 17y ago

Now I'm the middle of rewriting a good-sized software system. The reason for this is, we had to a add a completely new security level on top of our data (user accounts, groups, individual column access). There's just no way we could've refactored our already tucked-together legacy code. This thing was passed along 4 different developers, each constantly adding new features and I'm surprised it hasn't exploded yet.We're getting calls every day cause something broke again. So yea sometimes rewrite definitively makes sense and I'm sure our customers will love it.