Slashdot Mirror
Rewrites Considered Harmful?
ngunton writes "When is "good enough" enough? I wrote this article to take a philosophical look at the tendency for software developers to rewrite new versions of popular tools and standards from scratch rather than work on the existing codebase. This introduces new bugs and abandons all the small fixes and tweaks that made the original version work so well. It also often introduces incompatibilities that break a sometimes huge existing userbase. Examples include IPv4 vs IPv6, Apache, Perl, Embperl, Netscape/Mozilla, HTML and Windows. "
As a coder I can assure you that working on somebody else's code is frustrating because you allways say: "I would have done this differently". Most rewrites I think come from there, having the idea of a better implementation.
Microsoft: Ok, Windows XP and 2003 have a full rewrite of the TCP/IP stack and security system.
Slashdoter: Why did Microsoft rewrite the core OS? They just introduced more bugs and lost the stability and security fixes from older versions of the OS?
"Have you ever thought about just turning off the TV, sitting down with your kids, and hitting them?"
The minor tweaks, fixes, and changes that made the old version work so well can only go so far. Such is often the nature of code. Tiny fixes and patches are (sometimes haphazardly) hacked on to the code.
Perhaps if true extensive software engineering and documentation techniques were followed, a full rewrite may not be necessary. However, as long as quick fixes continue to pollute the code and make it more and more difficult to work with, an eventual total rewrite will always be necessary.
I'm sympathetic to the idea behind this article, but does it deserve a place on /.? There's absolutely no empirical data, or even a reasonable example given in the document. The author is talking about IPv6 and Perl6 both of which are unknown quantities at this point.
He's right that just throwing away old code means yo u lose a lot of valuable bug fixes, on the other hand if you look at some code and realize there is a better way then the solution is to rewrite it.
Of course you can have it both ways. What you do is write an automated test case for every bug that you fix in your code. When you write the new version it has to pass the old test suite, then you've got new code and all the experience from the old code.
John.
This oughtta be good. (puts on asbestos-lined pants)
The other side of the rewrite issue is, how long can you continue to maintain code from a legacy system? I worked on a project a couple years ago that had been migrated from assembler to COBOL and is now being rewritten (as opposed to being redesigned) for Oracle. Nevermind for a moment the fact that the customers wanted to turn the Oracle RDBMS into just another flat-file system--which included designing a database that had no enabled foreign key constraints and that was completely emptied each day so that the next day's data could be loaded. . .
Some of the fields that are now in the Oracle database are bitmapped fields. This is done because there's no documentation for what those fields originally represented in the assembler code and because the designers are afraid of what they might break if they try to drop the fields or attempt to map the fields out into what they might represent. I had the good fortune to get out of the project last August. . . last I checked, they had settled for implementing a Java UI over the COBOL mainframe UI.
Anyway, my point is this: at some point, you have to decide whether the system you're updating is worth further updates. Can you fix everything that's wrong with the code, or are there some things you'll have to jerry-rig or just shrug your shoulders and give up on? Under circumstances like what I mentioned above, I truly think you're better off taking your licks and designing from scratch, because at least that way you can take advantage of the new features that more recent database software and programming languages have to offer.
!#@%*)anks for hanging up the phone, dear.
As I recall, Torvalds made mention that some of his original code in the Linux base was not very good and he would have written it much differently today. Indeed, most anyone that habitually programs naturally becomes more skilled and if the underlying premisis/framework/model of an application or tool is not as good as could be - or is lacking a certain methodology that time has proven to be beneficial and only rewriting it will solve this - what is wrong with rewriting the code from the ground-up?
Joel on software has covered this point in a good article: http://www.joelonsoftware.com/articles/fog00000000 69.html.
Very true... One of the few "rewrites" that Microsoft has rever done is the NT codebase (which was actually more of OS/2 morphing into NT), and that wasn't a true rewrite since the "original" DOS/Win31 codebase keps livingo on with Win96/98/ME.
MS has tried some rewrites (I think they tried in Excel rewrite, I think Code Complete references that) but scraped them (also never giving up on the previous generation codebase).
That's one thing they do well (for better or worse) is not waste any money on rewrites (look at Win9x)
Rushfan
The Problem: Rewrite Mania
...
Waaaaaaa!!
Case 1: IPv4 vs IPv6
Waaaaaaa!
Case 2: Apache 1.x vs Apache 2.x
Waaaaaaaaaa!
Case 3: Perl 5.x vs Perl 6
Waaaaaaaaa! Waaaaaaaaaaa!
Case 4: Embperl 1.x vs Embperl 2
Waaaaa!
Case 5: Netscape 4.x vs Mozilla
Waaaaaaaaa!
Case 6: HTML 4 vs XHTML + CSS + XML + XSL + XQuery + XPath + XLink +
XML is hard! My HTML for Dummies book weighs too much! Waaaaaaa!
Case 7: Windows 2000 vs Windows XP vs Server 2003
Waaaaaaaa!
Conclusion: In Defense of "good enough" and simplicity
Waaaaa waaaaaaaaa!