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. "
Maybe im just not getting the point of this. This is generally understood concept when planning a rewrite....
Im glad
Was it a "good idea" for Microsoft to rewrite Windows as XP and Server 2003? I don't know, it's their code, they can do whatever they like with it. But I do know that they had a fairly solid, reasonable system with Windows 2000 - quite reliable, combining the better aspects of Windows NT with the multimedia capabilities of Windows 98. Maybe it wasn't perfect, and there were a lot of bugs and vulnerabilities - but was it really a good idea to start from scratch? They billed this as if it was a good thing. It wasn't. It simply introduced a whole slew of new bugs and vulnerabilities, not to mention the instability. It's just another example of where a total rewrite didn't really do anyone any good. I don't think anyone is using Windows for anything so different now than they were when Windows 2000 was around, and yet we're looking at a 100% different codebase. Windows Server 2003 won't even run some older software, which must be fun for those users...
the obvious answer is; "it's never enough". So, next article.. ;)
.. as they are rewriting the security layer!
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.
While mine is fine like wine.
--
You sure got a purty mouth...
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.
Microsoft has created an entire, successful, multibillion-dollar-a-year-profiting business model off of this!!
Sheesh.
do() || do_not();
In light of the preceding article, I propose that we completely rewrite slashdot! In BASIC! This will provide unsurpassed slowness and crashing, making the world better for all!
- - - - - - -
Orppf urp mf y.ppcxn. yflcbi otcnnov C am yflcbi yr n.apb Ekrpatv (Dvorak -> Qwerty)
Did anyone else read this and wonder if your cd/dvd RW's were at risk?
The trick is to include all the tweaks and fixes that were implemented in the old code. Obviously, if you rewrite and then leave open all the gaps and problems from the earlier version, there's no point in rewriting. However, you could rewrite with those fixes in mind, and come out with a completely new (and problem-free) edition.
I think it may have something to do with programmer ego and something to do with the challenge. I'm guilty of it myself. You find something you're interested in and you want to build it. It doesn't matter if someone else has done it or even done it well before you. The challenge is to do it yourself.
~ "When I'm of that age I'm just going to live up a tree."
...the next article will postulate that new versions of software can introduce new bugs. Egads. This is news! Glad I'm not a subscriber.
In Windows Longhorn's case, I think an entire rewrite (or close to it) is a good thing.
There are so many unfixable flaws in the way Windows is built, and there are some other flaws that could be fixed -- but it'd require doing some major patchwork.
We won't know just how secure Longhorn is going to be until 2006, but if the past is any indication... well... yeah.
Did you eat lots of paint chips as a kid?
I didn't RTFA, but Windows, seems a pretty bad example of an useless rewrite, if we're talking about the rewrite from 9x to NT5
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?"
As projects get older, and developers get more experience in the programming area they often look back and find better ways of doing things...take a look at Enlightenment 17 development. They are constantly going back and making it better than what was initial scoped out. I would not be suprised if the next version is lightening fast than 16
Ok, this dude uses netscape 4.x and thinks its fast. next article please.
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 think rewrites are good, as long as they're done correctly. When fixes or compatibility issues are added to the initial version, they should be well commented and documented so that they are accounted for in any rewrite, and tested if the logic of the program has been rearranged (perhaps to better fix bugs in the first place). Ideally a rewrite makes it easier for bugs to be fixed. At the same time a program shouldn't need to be totally rewritten more than a couple times. After one time the code should have enough modularity so that pieces can be rewritten with small impact at a time.
I don't try to be right, I just try to make people think
I wish someone would rewrite 'ls'. It really needs to be optimized.
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.
I can see one good need to rewrite -- when old techniques no longer do a sufficent job. Take Perl 4 for instance. It's simple, yes, but not extendable. You had to write your own libraries of Perl code to do more complex tasks (sirc, anyone?). Then Perl 5 comes out... and introduces package spaces and Modules, plus alot of cleaner code!
A few of my perl scripts were just hacks. Patchy hacks that were dirty and buggy. I rewrote one, Anything, to be cleaner. Oh so much better.
--
# Canmephians for a better Linux Kernel
$Stalag99{"URL"}="http://stalag99.net";
Ouch! There goes my karma!
"if we just stayed in the same place, using the same versions of tools without improvement, then things would deteriorate"
I don't see why things wouldn't simply "stay the same". You should probably rewrite the whole article.
Although I have an unhealthy habit of wanting to start things from scratch, I believe it can be a good thing more often than not.
When you've developed a piece of software, fixed its bugs, and tweaked it, more times than not, those fixes and tweaks are nothing more than workarounds for your currently flawed structure. Usually, you don't realize these flaws until AFTER you've created it.
By starting it from scratch, you can keep your mistakes in mind, and make better and more efficient software.
Sure, there are chances of running into new bugs, but isn't that what the whole learning process is about? The more you learn, the better the software will keep making. You can only go so far, if you need to turn a paper bag full of feces into an operating system. But if you start from scratch, you can create your own digitized significant other. You know, relatively speaking.
- shazow
This oughtta be good. (puts on asbestos-lined pants)
Your point is well taken about ego often driving rewrites but in my experience the driving force for rewrites is often maintainability.
As a program ages and drifts from the original intent ugly hacks are often placed on top of the original code to add unforseen functionality. There is also the opposite effect where old code is sitting around that no longer has any function. I remember one drastic case of this when rewriting a program where only about 1/2 the code was even beeing utilized.
By rewriting the code you clean things up and make it easier for future programers to understand what the code is doing.
One should not theorize before one has data. -Sherlock Holmes-
For Windows users, Winamp is probably the best example I can think of. Take a stable, usable, simple and elegant audio player (Winamp2) and fuck it up by writing it from scratch (Winamp3), then ultimately abandon that clusterfuck rewrite in favor of yet another rewrite (Winamp5) that fixes what they fucked up with Winamp3.
I'm mighty happy sticking with Winamp2, thank you very much.
Don't rewrite. Refactoring code is the way to go. Refactoring in small pieces allows the app to maintain compatibility as the process progresses.
2003: HAHAHA, M$ IS TEH SUX, thye shuld reWritee tehir WINDOZE from sctratch!!! HAHAHA!!!
2004: HAHAHA, M$ IS TEH SUX, thye reWriteed tehir WINDOZE from sctratch!!! HAHAHA!!!
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.
First of all, there is such a thing as good enough. Take a look at a lot of the gnu utilities. Some sit at version numbers like 0.17.0, because they're good enough.
However, big projects are obviously more complicated, and a lot harder to get right. There is a lot more to a program than just the source code. It is entirely possible for the source code to be totally bug free, and yet for the product to be fatally flawed. The problem is the design of the program. In all of the cases mentioned (that I have any knowledge of to begin with) the design of the original was flawed. Rewrites may toss out well tested bug-free code, but they do so in order to create well tested bug-free designs. I will gladly take a good design and buggy code over good code and a bad design any day.
Yo, moderators...
Yeah, really. Mod the whole stinkin' article flamebait.
-A
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?
So we should stick with IPv4?
John Kerry is a Joke!
This guy is full of shit and has no idea of what he is talking about.
Some of the better parts:
- He claims that The mozilla project and everything Netscape >4 is pointless and that Netscape 4 "just works". We all know that Netscape 4 is an awful, crashy, buggy, standards-breaking piece of crap that set the Internet back years.
- He claims that Windows XP was a complete rewrite. Windows XP is NT 5.1 -- (check with ver if you want) Windows 2000 with the PlaySkool OS look.
When is "good enough" enough? ... 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.
I don't get it. Windows 95 was a piece of crap. Are you saying they should have extended that codebase, instead of developing Windows NT onward, into WinXP? Basically, you're *complaining* that Microsoft acknowledged the crappy, unstable nature of Win95, and tried to create a better product?
What kind of fucked-up bizarro-world logic is that?
The theory of relativity doesn't work right in Arkansas.
Okay, so most of the article consists of, "Here's software X. They re-wrote it, and now it's not as good or as accepted. Why'd they do that? They suck."
Software is re-written for many reasons. Sometimes it's ego, sometimes it's for fun, but usually it's because you take a look at the existing codebase and what you want to do with it in the future, and you decide that it's going to cost a lot less to implement the future features by re-writing and fixing the new bugs than to work around the existing architecture.
I've had to make the re-write or extend decision more than once, and it's rarely a simple decision.
What I would have preferred from this article is some interviews with the people responsible for the decision to re-write, and what their thinking was, as well as whether they still agree with that decision or would have done something differently now.
=Brian
There is nothing so good that someone, somewhere, will not hate it.
Sometimes, rewriting from scratch is necessary to remove bugs. Not all bugs are just failure to check a buffer overflow, which can be fixed without a complete rewrite. Sometimes your basic communications architecture in the program is fundamentally flawed and insecure. At that point, by the time you've fixed that bug in the existing codebase it would have been easier to start from scratch and make everything else work "natively" on the new internal standard.
;-) There are fundamental security issues with all GUI windows operating in the same user space. If one is compromised, they're all 0wnz3d. That's a reasonably major flaw, but to fix it would require essentially rewriting the entire GUI portion of Windows, because it's so integral to the system. To try and fix that without a rewrite would be harder and more complicated than chucking it and starting from scratch, and probably introduce a dozen other bugs in the process.
:-)
Take for example, Windows.
Sometimes you really do need to throw out the baby with the bath water, if the baby is that dirty. Besides, making a new one can be fun!
--GrouchoMarx
Card-carrying member of the EFF, FSF, and ACLU. Are you?
Joel on software has covered this point in a good article: http://www.joelonsoftware.com/articles/fog00000000 69.html.
Who is this guy? Rewrites done properly and for the correct reasons are great. One would think after seeing everything Microsoft spews out that people would realize heaping code on top of code isn't good. For starters it is unlikely that you have the same programmers working on a codebase after more then a year or two and most code isn't exactly well documented. So you see dupplications. As for getting read of tweaks? Huh? Where does he get this stuff?!?!? Then again if you read the artcile he still uses Netscape 4.08, WTF? it has known bugs out the yingyang.
So back to my first question, who the hell is this guy?
There is only "good enough for now". Rewriting software is good from several standpoints:
1. It may be possible optimize slower areas of the code
2. It may be possible to take umpteen patches and merge them into the regular code flow
3. It may be possible to move modules outside the main code base
4. etc., ad infinitum
X. it may be billable as a new product (for commercial software only)
Anyone who sits back and says a given codebase is "good enough for now" needs to be consigned to the scrapheap of history and quickly. You should always keep an eye out fot a better way.
To celebrate the occasion of my 1000th post, I will post no more forever on Slashdot. Goodbye.
It was too messy and unmaintainable. I'll wait until the rewrite comes out to fix all the grammer and spelling bugs.
Hmmm.. rewrite good or bad?
Try Mozilla classic.
then
Try Firebird and Thunderbird.
Firebird and THunderbird taking over...
I notice the author brings up Perl 5 versus Perl 6.
What he doesn't do is bring up Perl 4 versus Perl 5. Or Perl 3 versus Perl 5. Or Perl 1 and Perl 2.
Perhaps it's because he's happy to admit that, unlike his predictions, old versions really do die out because their successors are so much better.
As a video game developer, I've been involved in many "code upgrades", as well as rewrites. As long as the rewrite is being done by people who wrote the original code, and they invest time in some preproduction carefully thinking through what they did right and wrong, the rewritten product will always be faster, more stable, easier to maintain, etc. etc. In the end it's always been a clear winner.
I know I always get a real buzz when I start with a fresh clean slate.
However, I know that often that biggest gain will arise from the difficult mental process of working with what I already have. It is hard because it forces me to question myself.
/* This sig is disabled. Press CTRL-W to enable. Thankyou */
Not even that the new addresses are 128 bits long and not 64 like he states repeatedly...
And prefering Netscape 4 to Mozilla, I want some of the stuff he takes...
Apparently IPv6 will solve all these problems, with a brand new standard that uses 64 bits.
Many, many applications work with IPv4 and assume that addresses will be 32 bit, not 64 bit (as IPv6 specifies).
That's a pretty glaring error, if we're talking about the same IPv6 spec.
I do't kow what you're talkig about. I spelled damed correctly.
"Have you ever thought about just turning off the TV, sitting down with your kids, and hitting them?"
Things You Should Never Do, Part I
From my experience anyway. I digress, this is in the context of university assignments, where a rewrite takes a matter of a few hours, but I've had code that refused to work even though I could trace it logically and there didn't seem to be any problems. After getting fed up, I toasted it and started from scratch, with the fresh idea in my mind of how it was supposed to work, and it came out perfectly.
This is a joke, right?
Please tell me it is a joke.
There is often a good reason for the rewrite, or the fork, and there is no reason why fear of introducing bugs should stop a rewrite.
The key is to use refactoring methods to do the work, rather than rewriting from scratch. Implement a unit test framework for the software you want to rewrite, and then do the rewrite through a process of incremental change, running the test suite after each change. This method reduces the risks that would otherwise make the effort seem foolhardy and not worth the effort.
--
“Doh!”
I had to force myself to keep reading the article after the first case study. The simple fact that he cannot even get his facts straight (IPv6 has a 128 bit address space) does not help his argument.
For a much more coherent argument against re-writes see Joel on Software, where he argues throwing everything out and starting fresh is a bad idea. He argues for evolutionary refactoring away old code.
Rewrites are 'bad' from a management point of view (at least, a manager that isn't familiar with software development), which looks at return on investment (ROI).
However, from a developer's point of view, a partial or complete rewrite is sometimes the only way to FIX certain bugs. While it may introduce new, small ones, usually developers are smart enough to read the old code and learn from it's mistakes before the do a rewrite.
A partial or complete rewrite is ALSO sometimes the only way to fix 'spaghetti code' -- code that's become so tangled from patch upon patch being applied to it that it's now impossible to trace and fix a bug. If spaghetti code isn't pursued and rewritten on a regular basis (this is 'constant improvement' -- a management buzzword from the past few years that actually works), new bugs can be inadvertantly introduced -- and it can sometimes take weeks to hunt down an intermittant bug by tracing spaghetti code. Ladies and gents, WEEKS of programmer time is expensive compared to one programmer spending 8-10 hours per week tracking down bad code in the codebase and rewriting it.
Really, there's a case for doing rewrites on a constant basis. The author should have instead addressed adequate testing in software development environments...
--
Vote for your hopes, not for your fears - Vote Third Party
Perhaps it has something to do with the fact that as technology changes, and the ways technology is used changes, the original design fails to efficiently and effectively meet the needs of the users. New features and functionality that weren't considered in the original architecture add stability and security issues. You reach a point where it makes more sense to take all of that knowledge gained from the current codebase and build a brand new one that takes into account all of the tacked on features and enhancements. And you will have to do it again once the "new and improved" version has been revised a few dozen times.
this is getting old and so are you
blog
The Aqua interface for OS X was completely rewritten for 10.2 Jaguar last year, and it was amazing. Things got alot faster and more intuitive.
without it rewrites are dangerous. Well, just about any coding is :)
This guy is just pissed he has to learn new stuff.
"Karma can only be portioned out by the cosmos." -Homer Simpson
Comment removed based on user account deletion
Woohoo! he's discovered the second-system effect. Can I recommend people read some of JWZ's netscape ramblings, and "The Mythical Man Month" by Fred Brooks, Jr.
Gary (-;
As a software designer, developer, programmer and user, I have to saw that rewrites done right are A Good Thing(TM). When I do a rewrite, it is with the intention that it is to be better than the old one. I only do rewrites when a limitation of the old code base has been reached or can be foreseen to be reached.
When a rewrite is to be made, it goes without saying that anything learned from previous development should also be applied to the newer project. If you can't learn from the mistakes of the past, don't do a rewrite.
It is not rewriting, per se, that is the problem. It is choosing WHEN to do a rewrite. Unless there is sufficient reason to do one (ie. old code hard to maintain, scalability problems, old code reaching its maximum potential, etc.), of course one should stick to improving on existing one. If, however, the reason is that so "we could have something new", or so that "we could say we did a rewrite" or "I'm the new architect around here. Scrap the old code and write my design", then of course rewrites might be more trouble than they're worth.
All common sense.
How can you say rewrites are bad? That is simply ridiculous. Without rewrites, there would be no progress. Sure, people get inconvenienced, but it's a minor inconvenience relative
There are some rewrites that are simply horrible and make no sense. But every single one of the examples that the author gives is an example of a GOOD rewrite!
Apache 2.0? Mozilla? Perl? This is ridiculous. I love Apache 2 and Mozilla (I don't use Perl) and find Mozilla much smoother to use than Netscape. These are platforms that people will be using going forward. If going forward is impeded by the current architecture of the software, YOU NEED A REWRITE.
A bad rewrite is when it completely breaks everything and no one migrates to the new version because there is no gain for anyone involved.
And Windows 2K -> XP -> 2K3 were not rewrites. They are evolutionary changes... now the author doesn't think that software should be improved or changed to add functionality???
If an application was designed correctly then it could have a much longer life. Just look at the physical world, good buildings, beautiful structures are around forever. Bad ones are burned for insurance claims. I think bad design is rampant in our profession, and I'm as guilty as anyone.
When you rewrite a project, it is obvious it is going to cause new issues. If you are paying attention, you make use of experience and/or at least view the patches and changelogs of the product you're replacing so that you don't incorporate too many of the old problems along the way.
...
What I've read seems like most who worked on Netscape 2.x through Netscape 4.x would agree it was time for new architecture. It was probably time for new architecture in the Netscape 3.x timeframe but corporate pressures were high to produce quantity instead of quality. The codebase was just too rigid, especially in the rendering engine, to keep up with emerging standards.
The point is that -not- rewriting may be safer in the short term, but often guarrantees your product is going to have feature lock and eventually obsolescence.
A bit of a push off-topic, but I think this is a lesson I think TiVo may be about to learn the hard way as most of their new versions are only new feature releases, not updates to improve the core of how the products work, which has begun to limit the efficiency of their product (ie, as the drives in the product get larger, the inefficiency of how the TiVo handles it's database becomes more apparent) and what types of features that they can add. I'm not saying they need to scrap everything, but rewriting some of the underlying system is going to have to happen at some point.
It is more productive to voice thoughtful opinions (reply) than to judge (moderate) others.
From the Perl 6 development webpage:
"The internals of the version 5 interpreter are so tangled that they hinder maintenance, thwart some new feature efforts, and scare off potential internals hackers. The language as of version 5 has some misfeatures that are a hassle to ongoing maintenance of the interpreter and of programs written in Perl."
For me, this is a necessary and sufficient condition for rewriting something.
Another one is: When changing the original will take longer than rewriting from scratch.
HCG 50a = 2MASX J11170638+5455016
11h17m06.4s +54d55m02s
I've rewritten entire projects because they had entirely the wrong design, difficult to maintain, unreliable and would never have been capable of performing what they sought to do. (If you bring in consultants to start a project, you are often guaranteed to end up with code like this.) That's not to say that I haven't looked for ways to keep existing code where it could fit in the new structure, but it's often just absolutely necessary, and often the hardest thing to explain to whoever it is who's paying the bills.
Sometimes legacy designs do cripple a potentially good system. I also think that Mozilla is an example of good to come out of the "We ought to rewrite this" camp - it took an age to appear, but once it did, it was excellent, far better than anything else (and still is.) Some people took exception to Mozilla's relatively slow user interface and rewrote those entire chunks (Chimera/Camino, Galleon, Phoenix, and others), and these, again, proved to be worthwhile rewrites.
The critical thing when rewriting a project is not to get carried away. Frequently 90% of what's needed is restructuring, not rewriting per-se. Old code can often be recycled and restructured to fit into the new framework. But sometimes it's absolutely necessary to call a halt, realise a lemon is a lemon, and create something fresh.
You are not alone. This is not normal. None of this is normal.
The correct word is "damn" as in the interjective vulgar.
YOUR spelling of "damed" would possible mean one of two things:
Either as an adjective (-ed) form of "dam" which is what holds back water.
Or as an adjective form of "dame" which is a slang term for a female.
Often times people will spell "damn-it" (correctly spelling) as "dammit" (incorrect but accepted spelling).
HTH HAND
Enlightenment DR17.
Stating on Slashdot that I like cheese since 1997.
Don't like perl 6? Use perl 5. How is this an issue? Unless you cast your lot with the cult of Gates, old poducts last a long, long time before they're considred useless...
Every successful piece of software I've ever worked on was rewritten at least once, by the same team (or by myself on private projects) in the process of development, fully or at least partially.
The fact of the matter is, even if you hire an expensive architect and have him do a good job, he's not a God. When you develop software some parts of it tend to become ugly as heck and you can't help but think on how to do the same thing better and/or with less effort, so that it won't become a PITA to run, maintain, improve and extend. When you reach critical mass, you become "enlightened", throw some shit away and rewrite it to save time later on. In all cases where I've seen it done I think it was worth the extra effort. I also think re-engineering code as you go saves money long-term if it's done reasonably.
All of this, of course, doesn't apply to those who start their separate standalone projects even though there are dozens of other reasonably good projects to contribute to (and maybe rewrite some parts of). Freshmeat.net is full of examples.
There comes a time when code evolves to much more than what it was originally designed for. New requirements added to an already old codebase often require major hacks to get working for a deadline, and never get reworked, despite the programmers best intentions.
There comes a time to take a step back and look for patterns, useful idioms. Occasionally things can simply be refactored, but just as often a fundamental shift in program logic results.
And hey, writing new code is always more fun that mucking around old code!
Well, software has a well-known life cycle, and this is what forces developer to rewrite code. After some point in the life of a software project, bug fixing and adding features becomes so complicated that it is not cost effective to maintain the software anymore. It is simply better to rewrite with the new set of requirements derived from the life of the original project. Apache is a good example. The old version works very well, but adding each new feature is a nightmare, so they collected the existing requirements, and using their new insights coming from years of experience they rewrote the whole system. Sure, it will be a while before it is as stable, but the code is much better. Also, I can think of many example in which the rewrite ended up being much better, such as Netscape, the rewrite of Mosaic.
Yay, another Dame Edna fan !!
You can think about all of those tweaks, inserts, and modifications as increasing the disorder in your codebase. I suppose that sometimes the best option would be just to start from a pure state and try to build back up to the same point with more order to your code, rather than re-purify old code. Either way, something will break, but I think coders would rather start from scratch than try to simply the nuances.
Re-writing Netscape from scratch was a good idea.
The car was broken, had 100,000 miles on it,
and couldn't keep up to speed on the freeway.
Putting on new tires, cleaning it and putting
in a new battery wasn't going to fix it.
The same damn reason you buy a new car is the
same reason you build new software.
While the article is a good rant, it's just wrong sometimes. For instance:
* He says that IPv6 uses 64 bit addresses. It uses 128 bit in reality. You would think that, if you were saying why something was bad, you'd do some basic research?
* Also in the IPv6 stuff, "TCP/IP works pretty well". So? TCP/IPv4 and TCP/IPv6 are the same damn thing. That's not an argument against IPv6, it's an argument for knowing what you're talking about.
* Perl. Sorry, the reasons for moving to the model in Perl 6 is well documented and sane. There's some problems with Perl 5 that we can't get around without losing backwards compatibility (syntax braindamage, for instance).
* Mozilla. Ok, it's slow. The Mozilla team even admits it at this point. MozFirebird is better. The reason for starting fresh wasn't speed, it was because the old codebase sucked.
* HTML. Having a language for both layout and data sucks. Splitting it into 2 parts is much better. There are developer perks, too (no rewriting the website to make it look different, no playing with layout to add data).
The basic point he seems to be missing is: a major version change (1 to 2) is supposed to be a radical update. The version system used by the kernel (and a lot of OSS projects) is based on that. Major.minor.revision. Bump revision when making bug fixes, bump minor when adding features (without breaking too much API), bump major when it's something new altogether.
-- Bill "Houdini" Weiss
Netscape 4 is horrible. It's usage is actually slowing down adoption of Mozilla and other far superior browsers. Once we start creating web sites with standards rather than with code that looks like HTML we'll have smaller browsers that can do things much faster than what Mozilla can do today. Indeed Mozilla isn't just one browsers but multiple browsers for all the F'ing crappy implementations of HTML there have been. Just look at the page this article is on. It's ladden with mistakes, isn't even standard HTML 4.0!
This guy would prefer to see the net stop growing than see some change so he doesn't have to rewrite some stuff. Lazy ass.
The problem with software is that it does not change over time. The engineering comunity already knows that "rewrites" need to happen. Every year there is a new car line, a new fridge line and even a new game box line.
The software industry needs to do the same. The trick is how to pay for it. If you dont change your product and somebody else does and makes it better, then you loose. If you do make changes and nobody else likes it, you loose. Look at the car incustry, the same happens.
This is what business is all about.
I wrote 3 years ago a web-app based on perl that is currently the heart of one of the tasks my company does. I am in the process of completely rewriting it in php and using no code or concepts from the first iteration in the new release.
Why? I have better way's of doing things now, I need to be scalable to handle a worldwide company instead of simply a regional tool, and to increase speed, useability and stability.
a rewrite is the only way to achieve these things. anyone who has been with a project for an extended period of time and had to expand/modify it beyond it's origional capabilities knows this.
Do not look at laser with remaining good eye.
Don't like Mozilla? Use Mozilla Firebird. Honestly, I can't think of any browser I've used that is better than Firebird (especially with the addition of extensions). Firebird should be enough proof to this guy that Mozilla was a step in the right direction.
Maybe I just get stuck with ugly projects, but my take is requirements change. Assumptions that were true when things started usually are not the case a few years later. Maintaining that code usually means that you end up with legacy kruft that you would not add if you were rewriting today. For me, when the legacy baggage is too painful its time to rewrite.
Sometimes old means stable, sometimes not... The trick is to know when it is time for a clean bowl and not get entangled by the 'not created here' syndrome when making that decision.
+++ UGUCAUCGUAUUUCU
IANAP(I Am Not A Programmer)
IAAET(I Am An Electronics Tech)
Generally speaking from a non programmer perspective, My company has recently released a new line of instruments using all "new" surface mount PCBs. All of our older lines were pass through.(Pretty easy to repair not more than 50 pins tops) All the bugs and defects were pretty easy to rework on these old boards now with the new and improved surface mount I am starting to see alot of the same problems that were fixed in the old PCBs but not many. As a whole the new instruments are much better faster with a better communication protocol(tcp/ip) versus our old proprietary interface that no one knows anything about becuase it was designed 20 years ago by a guy who doesn't work here anymore but I digress...
My point is that every company/project has to decide if going to the new version(or rewrite) adds enough signicant improvements or performace increases to out weigh the negatives of retracing bug fixes and reworks.
Of course good documentation of code or schematics' updates and reworks could minimize the amount of previously fixed problems.
It's all Politics
This topic has been covered, with much better writing, by Joel Spolsky:
Things You Should Never Do, Part I
Rub a dub dub
Yup. How'd you guess?
Second, of course Netscape 4 runs faster on your old machine than does Mozilla (even though you really mean Firebird, since Mozilla was always meant as a testbed, and Firebird was meant to actually be a stand-alone browser like old versions of Netscape). Most software released 6 years ago will be smaller and less featureful than its modern equivalents, and Mozilla does a lot of stuff that Netscape couldn't dream of.
Third, HTML vs XHTML+CSS+etc. You are not a web designer. Even if someone's paying you to do it, you simply can't hold that opinion and be anything more than a Dreamweaverist or Frontpager. Why? Because noone in their right mind thinks the old, kludge-ridden, variably-parseable, non-standard markup language that is HTML before HTML4.01/STRICT is better in any way than XHTML. Which is easier: changing the global font by editing each and every <font> tag in your entire website or editing a single CSS file? Repeat for colors, layout, link styles, etc. There's no way I'd ever go back to doing all that stuff by hand.
Sometimes rewrites are wasteful (see also second-system effect). Your examples, though, are awful. You listed several things that are not good enough, and that needed to be rewritten.
Dewey, what part of this looks like authorities should be involved?
Those who don't learn from the mistakes of the past are condemned to repeat them.
Wansu, th' chinese sailor
Thanks MS for bringing the PC to the masses.
I am firmly aware that if it wasn't for MS, then I would not be using a computer today, and I would be using typewriters... more over, I probably wouldn't have my job because Bill Gates. Thank you for inventing the GUI operating system and the PC.
However, I think IP V6, and XHTML, CSS etc, are entirely different beasts. They are "standards" not "code bases". Quite different in nature, ragardless of which side of the individual case one stands on.
Calling WinXP and 2000 re-writes seems just blatantly wrong. Both of those are basically WinNT - some of the multimedia stuff came from Win98/ME - calling those a re-write is really over the top.
No new insight, factual errors, and unclean separation of issues. Sorry, but I can't recommend this article as worthwhile reading.
p.s. How can anyone from the outside possibly know, if Apache needed a rewrite or not? I will trust the decision of the developers, rather than one from the outside.
When i coach CS students i sometimes say to them:
There comes a time in every software development project where the best thing to do is to delete all code and start again, perhaps you are there now?
But that is usualy when a student has started coding without knowing a squat about how to solve the assignment and realized after a couple of hundred lines of code.
This is my sig, show me yours
Ok, so I can see where there might be useful complaints about some things, but the Netscape/Mozilla rewrite was definitely not one of them. Netscape was dumping their browser development, they decided to open source it, and what they were allowed to open (after all the licensed stuff was removed) was unusable. The reason that there was a rewrite was not just because they thought it could be done better, it was because the people that maintained the Netscape code weren't all working on the Mozilla codebase and the new people couldn't read the Netscape codebase. It was a horrid spaghetti mess.
As for the rewrite of Perl or Apache, those are the things that need to be done, to move on with our life. For instance Windows NT was a rewrite from DOS/Windows. Was that a bad idea? Was Windows ME really "good enough"? Give me a break.
Ad-hoc fixes to particular problems lead to code bloat. Excessive code bloat leads to a desire to rewrite.
A full rewrite may have a cleaner architecture, but often, those fixes for particular, tiny problems are lost in the rewrite ("what is this two-line if supposed to do?").
The solution? Redesign, but get to the new architecture from the old architecture by refactoring, one small step at a time. To do it quickly and with confidence, do unit tests. Lots of unit tests. Ideally, those tiny problems that prompted the fixes should have unit tests specifically built to trigger them.
My website
There was a study done many years ago about bugs in software. I can't remember who did it, but he discovered that after a certain point it is impossible to decrease the number of total bugs in a given piece of software -- everytime a patch fixed one batch of bugs, another batch was introduced. He then postulated that the only way to create bug-free software was to never let bugs in -- aka clean-room programming. Unfortunately, most developers who rewrite software from scratch don't rewrite it using clean-room practices, and end up with a new codebase that is just as buggy as the old one.
It's not a matter of "taking off", as it already has in most respects. Sure, your average Joe doesn't an IPv6 connection... yet.
bgp02# sh ipv bgp sum
BGP router identifier x.x.x.x, local AS number xxxxx
385 BGP AS-PATH entries
If you'd look at the IPv6 routing table, you'd see just how many networks are being advertised already. IPv6 won't become widely used until NSP's and ISP's begin selling native links to residential users(target: 2005-2006). Which at this point in time, they have no real reason to do so. If you'd notice, most NSP's are peering up native IPv6 connections, or have some type of native transit. Most people don't purchase transit from them, because there's practically no residential end-users with native connections, thus they'd pay money, yet never use the link. (I personally beleive they should be giving transit away to current customers, in order to try and push IPv6, since in all honesty if you're paying thousands a month for ipv4 transit, why not give ipv6 transit away for free until it's a medium that actually generates traffic!)
We still haven't quite exhausted IPv4 address space, but we will, which was the major reason for IPv6. 128 Bit address space > 32 Bit address space.
-mpf
I'll probably get modded down for this, but the discussion seems less like a "philosophical look" and more like somebody pointing out what they don't like about various products.
all of the attention directed at linux has diverted much needed atention from minux. New patches for minux must be submitted in B, to avoid extra compiler maintenance.
You have to make an informed decision based on the sitution. Here at work, I inherited an old system that was designed in Excel, implemented in Access, coded in PHP by someone who didn't speak English, and then maintained by the biggest moron I can think of. More importantly, the requirements of the company had dramatically changed, and they needed a more stable, consistant solution to play with the "big boys".
In our case, we had to rework the system. It really needed to be done. Yes, we introduced new bugs when we did it. However, the improved design, performance, and usability of the tool have turned it into something users dreaded starting up, to something they'll happily use on a daily basis.
Before you start on any major new software endeavour, you have to plan accordingly. Count all your options (ego be damned), and the benefits of each. You can't just rewrite something cuz you get a wild hair up your ass, or because it's harder to maintain someone elses' code. Once you can provide a list of legitimate, well thought-out plans to rewrite, then you should seriously consider it.
~D
This sig has been enciphered with a one-time pad. It could say almost anything.
ermm IPv6 is 128 bits rather than the 64 the article incorrectly states.
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!
"Considered Harmful" is Considered Harmful.
There are 16.7 million addresses per square metre of the earth's surface, including the oceans. This is overkill.
That's untill nanotech comes up with microscopic airborne routers/servers...
Examples include IPv4 vs IPv6, Apache, Perl, Embperl, Netscape/Mozilla, HTML and Windows.
When? Where? How? From the above I know Mozilla isn't rewritten, Windows get a deep overhaul but are in no way rewritten, HTML is a standard, not a program so can't be rewritten (just got extended to XML) - I don't know about the rest, but this is definitely a troll, and not very good to that!
45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B2
One point that the author seems to miss is that there are better and worse ways of doing a rewrite. Several of the examples he mentions (notably Apache 1 vs 2 and Perl 5 vs 6) are being handled very well. Development on the old versions is continuing while the new versions are being improved essentially in the background. That means that nobody is forced to upgrade until the new version actually provides them with enough tangible benefits that the switch is justified.
Perl is an especially good example because the new version is actually separating the language specification (Perl6) from the Virtual Machine (Parrot). Parrot will be flexible enough to run both the old and new language specifications, so even people who don't want to rewrite their scripts will benefit from the performance enhancements. Combined with continued development of the existing codebase, this makes Perl very future safe, all while offering the potential benefits of a complete code rewrite.
There's no point in questioning authority if you aren't going to listen to the answers.
Here is my rewritten version of this article:
"Doh! I can't believe I just embarrassed myself in front of 1,000,000 geeks. I'll just go back in my hold now."
There, much better and it removes all the problems like Neil saying that Netscape 4.x is a good browser.
As a piece of software gets more and more useful, more people start to use it. And hence, more bug fixes and suggestions start to trickle in. Initially, those could be easy to fix, without any side effects, but at some point fixing one bug can introduce a myriad of other problems. The larger the code base is, and the longer the code has been in "production", the harder this becomes. Then, it becomes apparent to the coders that had they chosen a different design strategy, things could be easily fixed. When enough of those revelations happen, and when it becomes extremely frustrating to follow the numerous bugs resulting from a small fix somewhere else, the time becomes ripe for a re-write. And, if the re-write is done properly, then everything will fall nicely into place. A case in point is Perl5, which was a complete re-write from scratch, but kept backward compatibility with Perl4, and greatly enhanced upon it.
Also, the argument of "good enough" is a very weak one. I guess whether a tool is "good enough" depends on your intended application. Horses were "good enough" for most people to travel around with, before automobiles. Pen and paper were "good enough" for most people to calculate with, before computers. And the list never ends. But somebody, somewhere, always wants/needs more.
If humans had been content with "good enough", then we'd still be in the dark ages.
Why hasnt this dude been trolled yet?
Wow, that is one awful article.
The whole reason we have such great things as Perl is because some very smart people had an itch or two to scratch, and let us all have the results of their great work for free. That's called generosity.
If some of these very same people are now excited about other approaches to the problem, who are you to whine about them "breaking" things? Especially when the things you like and consider "good enough" are still available, for FREE, for you to use for the rest of your life?
When these very smart people go back to the drawing board and make something new, it usually results in something called progress.
"Ok, so Perl 5 will still be supported, but was it really so necessary to do the total rewrite and break the old code?"
Sorry, but until you are paying all these people for their time, it's really not yours to ask whether their projects are "necessary." If you don't feel like writing a new mysearchbot for Perl6, that's your business.
As for the Microsoft example, don't you think it's a little naive to consider the business model of a huge software company and the motivations of open-source developers in the same breath?
"When you rewrite you are abandoning history and condemning yourself to relive it."
Sweet. I wish you'd put that in a <blink> tag.
This Like That - fun with words!
... that when an app is maintained over time (enhancements, bug fixes, tweaks, etc), the maintenance programmer often does their thing will the minimal amount of effort required. This is because the maintenance programmer (a) doesn't understand the program as a whole (b) is under a time crunch (c) wants to avoid changing as little as possible to avoid introducing new bugs. Often the maintenance programmers work is hack-ish in nature, thus eventually leading to a situation where a change is requested where a rewrite is the better approach.
"With the advent of NAT and the use of non-routable IP addresses to handle LANs, the need for every device to have a routable address becomes lessened."
... why they didn't add more types to the INPUT form tags to express different types - for example, a DATE attribute, or INTEGER, DOUBLE, or whatever ... This would get rid of so much of the headache involved with parsing out this stuff on the server side."
Oh boy, here we go again.
"Case 5: Netscape 4.x vs Mozilla
I have a 450 MHz AMD K6-II workstation with 512 MB RAM..."
I call B.S. I ran Mozilla on a Pentium 350MHz with 128MB RAM without a problem. Mind you, I was running Linux+GNOME. The article doesn't specify what platform the author was using.
"Case 6: HTML 4 vs XHTML + CSS + XML + XSL + XQuery + XPath + XLink +
So you want to simplify HTML by adding a type system? Baahahaha. Ok, sorry. That laugh wasn't entirely called for. However, no one is saying that you have to use or know about XQuery, Xpath, XML, etc. Use what gets your job done. As far as CSS in HTML, it's not a big deal. You don't really have to even have anything special. so you learn a few style things like <span style="color: #ffffff; font-weight: bold;">it's not a big deal.
"But the direction we're going in, the HTML books have just become thicker and thicker over the last few years. And still, all most people really want to do is browse the web..."
If all you want to do is browse the web, what are you doing with an HTML book? If you want to write a 1995 web page, you can still do it using only <p>,</p>,<br>,<a> and <img> tags if you want.
"Case 7: Windows 2000 vs Windows XP vs Server 2003"
All the other arguments might go somewhere, but arguing about this to MS will do nothing. They have a bottom line to maintain. Releasing new versions, claiming a rewrite will improve things is neccesary for them to make money.
Most of the points that the author makes are irrelevant, wrong or just plain silly.
1) IPV4 vs IPV6 - Well, eventually we will run out of IP addresses (yes, I know people have been yelling the sky is falling for years, but eventually it will happen) and all of the new routers will support IPV6 so a natural progression will occur. Is IPV6 harming me in any way? No, and am I glad that slowly IP Stacks are being written for it, and one day I will wake up and IPV6 will be a reality.
2) Apache 1.x really didn't need any more work, and yes, I don't use 2.x anywhere yet (mostly because PHP doesn't work seamlessly on it yet), but it is MUCH better for windows and eventually I know that I will switch to it. As long as people still maintain security patches and the like on the old version, kudus for the much nicer architecture on the old system.
3) Perl 5 vs Perl 6. Well I guess we will see how good the backwards compatibility is when it gets released, once again silly to argue against something that hasn't even been released yet.
4) Don't use emperl, so I can't comment on this.
5) Netscape 4 vs Mozilla. Netscape 4 sucked. It was a bane to all web developers that had to maintain pages that worked with it. Half-assed CSS, a terrible dom, nasty hacks to make DHTML pages half work, and it was hardly light weight. Mozilla Firebird works just fine on my old PII-400, much better than Netscape 4.6 does so the argument that it is poorly written in specious. The CSS/DOM support for it is fantastic, it is faster than IE on windows, plus has features like pop-up blocking and tabs that you just can't get for Netscape 4.x.
6) Obviously the author hasn't done any real web development, or creates nasty web pages full of font tags, etc. CSS was a great development, and XML and its related technologies (XSL, XPath, XQuery, etc) certainly have their place.
7) Windows 9x and ME are based on windows ontop of DOS technology, Windows NT/200x/XP are based on the New Technology and are complete rewrites. XP is not a rewrite of 2000, it is 2000 with a different Shell. 2003 is 2000 with a bunch of new features added as well as a completely new security paradigm (disabled everything and force the use to enabled features one by one rather than the old Microsoft paradigm of enabling everything and forcing users to shut down services as their security holes become apparent.). Re-writing windows 9x was one of the only good things that Microsoft has ever done. The old dos/windows kernal was about as stable as a two legged table with an elephant perched atop it.
In short, sometimes things shouldn't be completely re-written to save time and keep things compatable, but most of the time after 5-15 years of cruft being added to it, it is good to take a fresh clean start and get a well designed architecture in place that you can build upon. Examples of this include
1) PHP - PHP2, PHP3, and PHP4 where all complete rewrites of the lexical engine (they kept the functions, but the parser was completely re-written and everytime it has only improved things). PHP5 the jury is still out on (I haven't tried running our legacy code on it), and it is more of an evolution than a re-write.
2) Windows 9x - 2000 - Windows 2000 is a real, stable operating system rather than a cobbled together file manager/shell on top of a 16 bit joke of an operating system.
3) OSX - OSX is much more stable than its predecessors, and actually supports modern OS features like pre-emptive multitasking.
4) Mozilla - It took far too long (and basically killed the Netscape brand) but the wait was worth it. Much better browser than IE, and the old Netscape.
There are more examples, but they don't quickly come to mind.
I really don't see the authors point about not having a font tag anymore - HTML wasn't intended to describe the look of the page in the first place. Besides, by using CSS significant bandwidth savings can be achieved, not to mention the ability to change the look of several pages by changing a single file.
...when he claimed that IPv6 addresses are 64-bits.
Also, he mentions Apache. Well, version 1.x forks when a new process is needed, version 2.x is multithreaded, therefore reducing the context switching load somewhat (switching threads as opposed to switching processes).
I am NaN
That's news to me. I thought it had 128.
Perhaps proof reading and fact finding should be among your "good enough" peeves?
It could also be argued that the 'enhancement' to Windoze 95 that produced Windoze 98 was a case where an incremental update introduced bugs all of its own.
Drill baby drill - on Mars
Harmful to re-write...harmful to use GOTO...urk...can't...move...
Obliteracy: Words with explosions
While I generally agree that reinventing the wheel is bad. Most of these seem to be unexamples.
IPv4 vs IPv6 - This is one of those things that has to change sometime. The sooner something like this gets fixed the easier it is for everyone.
Perl 5 vs 6. - As I understand it Parrot will run Perl5 code so who cares and there is enough developer mass behind Perl that the transition should be smooth.
Netscape 4 vs Mozilla - I'm runnig Firebird on a 400 Mhz Celeron with only 96Mb of memory and the thought of going back to Netscape 4 is horrible. Apart from speed I can't think of a sinlge thing that isn't better. And speed is relative since, browser crashes mean I have to refind the page I was looking at or giveup and use somehting else to view that page. In fact I'd say this is a strong arguement in favor of rewrites.
HTML vs a plethora of better standards - Why would you use netscape 4? It's broken. The problem with HTML is people and programs actually destroy information with it. We loose track of what belongs to what section of a document. Whats a title or heading and whats just bold.
Windows 2k vs 2003 server - From what I've gather they actually are improving. Though in a confused Microsoft manor. I doubt most people want to return to DOS of even Windows 98.
I'm not sure that the author of the story really discusses the give and take of patching an old codebase, vs a complete rewrite. Instead, he focuses on a negative that isn't really there.
As soon as I read the headline, the first apps that sprang to mind were Sendmail, and WuFTPD. Both have been historically full of holes, and a complete mess. I haven't really looked at Sendmail code, but having to configure each option with regular expressions, while powerful, is just lame (IMO). The WuFTPD code is a mess. It's been passed on and passed on, and patched and patched. It eventually became a total whore that nobody really wanted to touch on any level.
Now, both of these (AFAIK) were not rewritten from scratch, and suitable replacements have been produced all over the place. However, would it have been so bad to rewrite those from scratch, while still maintaining the older versions? How would it be any different from, say, the Linux kernel. I run 2.4.x on my production machines. 2.6 is out, but I'm not going to run it until it's proven itself elsewhere (and is integrated into a mainstream distribution). 2.4 will be maintained for a long, long time -- and it's not eve na complete rewrite (AFAIK). Usually code rewrites are adopted by the public...not right away, but eventually.
Finally, his gripe about Mozilla/Netscape are interresting, but not really warranted (and he does acknowledge this). The applications became more bloated as system resources became more plentiful. Software tends to do this -- it has to do with greater layers of abstraction as hardware gets better. But furthermore, it's because Mozilla had to be able to "compete" with the latest greatest from Microsoft...which MSFT will always be updating as new standards are added.
The point is, it doesn't really matter. It doesn't do a disservice one way or the other, and since much of the software we're talking about is Free Software, it matters even less, since the code it out there -- if there are enough people using the older versions, there will always be someone to maintain it.
-Turkey
..might include the "rewrite" of OpenBSD's packet filter. While the reason for this rewrite was motivated "politically" (license restriction of Darren Reed's ipf) it was a rewrite - and a good one!
The authors complaints about speed are unwarranted and conflict with my experience. Mozilla (the suite) is reasonably fast although I have switched to using the individual apps, Firebird and Thunderbird. Both are plenty fast and don't -- in my experience -- have any problems that make them unusable.
Makes you wonder that if after appyling all the patches needed to make Windows operate properly and securely, will it be a complete re-write of the original code?
"Look Lois, the two symbols of the Republican Party: an elephant, and a fat white guy who is threatened by change."
"Apparently IPv6 will solve all these problems, with a brand new standard that uses 64 bits."
No my friend, IPv6 uses 128-bit addressing.
version is a matrix of solutions to breakage of a solution?
Then it would make the continued development slower than h*ll, harder for new to learn. End result would be a WindowISMed version. Pure Horror.
---
Exactly when did Netscape ever work well on Linux?
All I remember is consistent crashing from Netscape Gold through the finally-put-down Netscape 4.x. It was the biggest piece of shit browser ever written precisely because its codebase was old (forked from NCSA Mosaic in 1994, which itself was much older) and non-extensible, yet more and more shit was thrust into it. It had to be rewritten, and all the Gecko-based browsers have been much more feature-complete and reliable for the past 2-3 years than Netscape ever was.
I use Galeon, and the thing basically never crashes. Back in 1999, I considered myself lucky if a particular version of Netscape 4.x only crashed once every half-hour.
[ home ]
Maybe times have changed, but when I started my career as a _maintenance_ coder, there were two ways to do it:
1) The usual way: fix small sections of code in the same style and technique that it was originally written,
2) rewrite large sections of code that were _truly_ hard to maintain, taking great care to leave something much more maintainable behind. This route requires much more thorough testing than (1).
I remember another of us "programmers" who said he didn't do maintenance, he was a "development animal." Wrote abysmal code. When he rewrote a major module of our system he tried to make FORTRAN look like ALGOL, using GOTO statements in the righthand margin of the code.
I bet that module got a rewrite not long after that. Something that was maintainable and written for the language that was being compiled, not the language that didn't even exist on our system.
Why not strictly control the propagation of networks?
Keep the the number of publicly routable networks down and grow with time as performance improvements all technology to catch up.
Conformity is the jailer of freedom and enemy of growth. -JFK
I didn't RTFA but considering the comments I've read so far, it doesn't seem like I've missed much.
The only cases I've seen rewriting instead of fixing the original are with smaller projects, like Xbox Media Player for example. For all intents and purposes, XBMP is dead. Pretty much all the original authors of XBMP decided to work on Xbox Media Center instead.
I remember a lot of shareware from back in the day that the same thing happened to... One day the author woke up and hated everything about it and decided to start over completely. Other than complaining about it (which is ill advised since it just pisses off the programmers), there's not much you can really do. To people that don't program, reinventing the wheel looks like a tremendous waste of time. If the programmers of an app you like to use decide it's time for an overhaul, they probably have good reasons for it and if that really bothers you, it's time to look for an alternative or just keep using the old version.
And hey, the good thing about apps that are open source, if some new programmers pick up the old codebase, it may still have some life left in it yet...
---
DRM is like antifreeze, to the MPAA/RIAA it's sweet, to the consumers it's poison.
I do not concur with the author's seemingly blanket assumption that a complete re-write of codebase is wasteful. There are times when it is necessary for both practical and philosophical reasons.
From the practical standpoint, and suggested by other astute readers, often times the initial specs did not sufficiently anticipate future growth. Needless, it is a poor programmer who does not from a programmatic perspective anticipate this and do his/her/its best to provide a sufficiently robust framework that has at least one order of magnitude growth in a primary spec. On top of this, standards change, new ones emerge, "paradigms" shift, needs change and so on -- at times it just makes sense to start from scratch. You are not going to build a business building on top of your house's foundation...it just is not scalable to the new needs.
Philosophically, I think it is worth tearing down the structures and building anew at times. Too much incremental growth can lead to long term stagnation as the original skills to build the foundation are lost through inactivity. As an aerospace engineer I can see it now where too much information and processes have become institutionalized -- I fear if ever we needed to do it from scratch.
The article claims that these platforms are "100% different codebase". I'd like to see where the author get this information. I have legitimate access to the Windows sources and I can tell you that each new release of Windows simply builds on top of the previous release. You wouldn't want to rewrite this stuff for each new release - for example, the WinXP sources is 5GB of source code alone.
The Gnome desktop environment is a prime example of disasters through re-writes.
As we all know, Gnome's oringal purpose was to provide a free rival to KDE, which was the first easy to use Desktop Environment for Linux, this was back before Qt was GPL
Unfortunaltey for Gnome, its problems started as it kept replacing and rewriting core components. For example, it started out with the Enlightenment window manger, then it switched to sawfish, then it switched to the buggy and slow metacity. Metacity has had many problems, and most people want the old sawfish back, but havoc pennington refused to do it and insists that people use it.
The file manager keeps changing too. First it was GMC, then it was the Slow and buggy Nautilus from the now defunct Eazel corporation, now they are writing a new Windows 95 like file manager for gnome called Spiral Nautilus.
It also rewrote the graphics layer GTK and broke compatibillity with GTK 1.x. There are many legacy GTK apps still in wide use and they look ugly on newer desktops.
There is also the many problems with the file dialog, which is now only emerging in GTK 2.4. This is also incompatible with older GTK versions. This means that if you want to use a new program, YOU HAVE to upgrade to Gnome 2.6, and can't keep your leagcy Gnome 2.0,2,4 desktops.
They keep switching default apps, for example, Galeon was dropped in favour of the buggy and far less featureful Epiphany in 2.0. They also dumped several other applications that were useful.
To make matters worse, it is going away from the old philosphy of simple text files and are using an XML based registry clone to configure stuff. KDE keeps the text file format underneeth and has had a standardized API for it.
It also has a lack of true intergration, Micheal de Incanta has PUBLICLY ADMITTED that Bonobo was a faliure. KDE has had this BUILT in from day one using kpart technology, which is now being used in Apples Mac OS X Panther Edition.
Gnome developers, realising they kan't kompete with KDE technology, has spread various FUD about kde, but the message is getting through. Red Hat has abondaned their Gnome desktops, Fedora developers are working hard to make KDE 3.2 the default desktop for Core 2. Debian, who has traditionally been pro-gnome have announced their full support for KDE and they are working hard to make KDE the defualt desktop for
KDE on the other hand has kept consistent technology and has internally has changed very little since 2.0. Distros like Lycoris are still using 2.x because it is very stable and mature. KDE 3.2 will be a good example of why maturity, and not wheel inventing is a better idea overall. They have took their technology and have optimized it for usabillity
Gnome 2.6 will need more than just propoganda about the HIG if it is going to get the attention it needs, but instead it looks like they are reinventing wheels again.
I'm not sure of the relative validity of these points... though I agree with the sentiment.
1. This is a Cisco problem, a general problem is in the points below:
2. I didn't know there were "16.7 million addresses per square metre of the earth's surface, including the oceans", interesting. The problem with the present system is the 'chunking' of IP addresses... large groups of IP numbers lay dormant, reserved for academic/government institutions, the portion of private addresses is being squeezed in places. The IPv4 problem is an allocation problem, but allocations are determined by committees, and as soon as disparate and opposed committees get going progress and action stop for years, yes it is annoying beaucracy, but a technical work-around may well be easier than fighting this pettyness.
3. A few years ago the internet was here and it did its job while processing power of out-of-the-factory internet infrastructure was so much lower than it is today. Volumes are higher now, the dotcom boom of endless financing has gone (maybe?!) but I believe the internet with IPv6 and its higher volumes could be cheaper now than it was (I am happy to have my mind changed with hard data but not supposition and not opinion based on loose facts and assumed weightings). Lecacy equipment and software has to be replaced sometime, all that COBOL was re-written pre-2K pretty easily.
4. See 3.
There may be "16.7 million addresses per square metre of the earth's surface" but if this can provide a solution for the next few decades, and is easier to overcome than the present beaucracy in IPv4 allocation (which is huge and incredibly difficult to overcome IMHO) then it is worth it.
--
FreeNET user? Comfortable with the adverse selection?
...if you have a product need the end of it's life and the function is smooth, sure, don't mess with it. But if the original programmers are gone, it is poorly documented and you have much plans for it, a rewrite could be worthwhile even with the new bugs just to provide the new team a way to get to know the problem better. Then they will be able to maintain it better and improve, not to mention have a great sense of ownership in it. It just depends.
Right. Copied from what, exactly?
. . .didn't think so.
!#@%*)anks for hanging up the phone, dear.
but this guy does not know what he's talking about.
I'd say that a majority of rewrites happen to facilitate progress. (wow, what a concept).
At some point in time, most software runs into a brick wall, when it comes to extending it.
I'll give you a very simple example (a better one than any of the examples that he listed):
Take a browser that was written to display HTML. Then came along JavaScript. Oops, the browser does not use DOM for its internal tree. Of course you could kludge this onto the original browser, and it probably will never work entirely correctly (go ahead and by the Spyglass, now OpenTV, browser source, you'll see what I mean). Or you could rewrite it with this new technology in mind. (yeah Mozilla is not the greatest source tree on the planet, I agree)
I really do not see the point of this article though. So we should just be patching up Netscape 4 for eternity? Or Windows 98? What was wrong with Windows 3.1? Should we still be using that then?
The author doth talk complete bollocks.
I hace 66MHz 486 running linux and mozilla - and it doth take only 6 seconds.
Seriously, if it is taking him 10 seconds to open a new window with mozilla on a 450 Mhz PC, then the problem does not lie with mozilla.
Instead of getting rid of useful tags and redesigning HTML as XML
Um, no. While there are a few sublanguages that deal with display (XSL-FO, XHTML), XML is mainly a data format.
Sometimes rewrites are good and sometimes bad. Often times when developing or expanding on somebody elses development you find that a different model works better.
Case 10: OS X Apple wanted to have a solid, memory-protected, pre-emptive multi-tasking, multi-processor friendly operating system. Their existing code base was a hodgepodge, some of it still in 68000 assembler and running in emulation. It was written for a single processor system with no memory protection, now supporting co-operative multitasking through the extension of a hack. Apple REALLY didn't want to rewrite this, angering developers and taking a lot of their time. So they tried to bring their current code base up to standard. They failed. Several times. Sometimes code really IS too crufty to save, and a rewrite is necessary. Whether Joel Spolsky thinks so or not.
Here's a much better article with a similar thesis: Joel on Software - Things You Should Never Do, Part I
There are parts of it that I've never agreed with:
This should never happen! If you have all these bugfixes in your code and no way to know why they were put in, you've screwed up badly. You should have each one documented in:
So the idea that you'd have all these important bugfixes without any way of knowing what they are should be laughable! Given a codebase like that, you probably would be better off throwing it out, because it was clearly developed without any kind of discipline.
Also, he's embelleshing a lot. If it's just a "a simple routine to display a window", it doesn't need to load a library, require Internet Explorer, etc., and thus can't possibly have bugs related to those things. He makes the situation sound a lot more extreme than it really is.
But in general, I think he's right. Refactor, not rewrite. That's the same thing the XP people say to do. They also have extension unit tests to make it easier to refactor with the confidence that you haven't screwed anything up. Which can help in situations like this:
Ugh. I bet it would have been a lot less tuning if there were a decent way to test that the change to support #60 hasn't broken any of the previous 59 server types. Or that just a refactoring hasn't broken any.
I don't think this advice always applies, though. I rewrite one major project from scratch at work: our personnel system. Our database schema was hopelessly denormalized and broken. That's not something you can refactor easily - with a widely-used database schema, it's easy to make one big change than many smaller ones, because a lot of the work is just hunting down all the places that use it. That's easier to do once. So I believe there are situations this advice does not apply, but I also believe they are rare.
And it's the coding craze that's sweeping the nation!
Google's your friend in this case, as usual. Lots of people have spoken on this subject. Heck, there's even a book or two about it.
For the uninitiated, Refactoring is the practice of restructuring a code base in a disciplined way (shamefully stolen from refactoring.com). Basically, you change the code's structure (hopefully in a good way) with minimal to no changes in the outward appearance of the software. This way, the code gets better (clearer, easier to maintain, etc.), without introducing new bugs and incompatibilities.
There are cases where it's just better to throw away your old code, but those are much rarer than people like to believe. It's almost always better to refactor.
--
Mando
It's hard to write code that is robust enough to not need rewrites. The ability to do that is what separates the really good programmers from amateurs like myself. It's the difference between being a piker (like myself) and an engineer.
I'm not a great programmer, and don't do it regularly, but when I have written fairly big projects, I find that the need for rewrites came out of poor design choices that I had made.
I typically start out with something small, that can handle the core functionality expected from the project. Then I try to add features and fix bugs.
Eventually, the code becomes very difficult to maintain, and ultimately, you get to the point where the ad-hoc architecture simply won't support a new feature.
To the user, everything looks fine, everything runs reliably, but under the hood, there are real problems.
My worst experience was with a web app. I started out with script based pages in ASP (not my call), and kept writing new pages to do different things. It got to the point where I had a about three hundred script pages and lots of redundant code.
When it would become necessary to change the db table structures for another app hitting the same data, I'd have a lot of trouble keeping up, fixing my code quickly in a reliable way.
The problem was that it just wasn't possible to stand still. I couldn't go to my boss and say, "I need a three month feature freeze, to rewrite this stuff."
Writing a new version in parallel was hard because maintaining the crummy but functional code was taking more and more time. It was a real problem, and caused me a fair amount of pain, and suffering.
After digging myself into that hole, I stepped back and tried to figure out how other people did it. I would have been a lot better off building on top of something like struts.
The lesson I took from this is that it's important to study design patterns, and to use tested frameworks whenever possible. You have to think like an engineer, and not someone who codes by the seat of his pants. I'm not an engineer, so it's not easy for me to do that.
I'm not saying that the people who run the projects mentioned are in the same boat that I was. As programmers, they're in a different league.
But they're often working on problems that aren't well understood. Patterns and frameworks are ways to leverage other people's experiences. But if that experience doesn't exist, you have to guess on certain design decisions, and see how it comes out.
Top notch programmers are obviously going to guess a lot better than someone like me will. But they're still going to make mistakes. When enough of those mistakes pile up, you're going to need to do a rewrite.
You could make a point that's opposite of the one that the article makes by looking at the java libraries.
They made choices with their original AWT gui tools that were just wrong. They weren't dumb people -- they just didn't know, the experience necessary to make the right choice simply didn't exist. Once they tried it, they realized it wasn't working, and they came back with Swing.
Rewrites are always going to be necessary for new sorts of projects, because you can't just sit in your armchair and predict how complex systems will work in the real world. You have to build them and see what happens.
Copied from a very recent story dipship. Why don't you find it to prove that the post wasn't copied? The post was copied.
The conventional approach to system engineering is to write a long and detailed spec, then implement the system and finally test it (eventually at the customer's site).
This approach tends to create many unnecessary features and many times important and useful features are missing because they were not anticipated. At this point the product is already late and these features get added as an afterthought (patches...)
The other way: write a simple prototype with the minimum features deemed necessary. Then continue refining or rewriting implementing all lessons learned and feedback received from users. This way unnecessary features are never implemented or get stripped early on, while useful features are continuously refined.
It really works.
Nimrod.
I am not a programmer, but I do work with several. If you correctly use object oriented programming then why would you ever need a complete re-write?
Our lead programmer here is always bitching at the other programmers for not writing their own classes, and making code reusable.
Once all of the old code has been either pasted back in, revised or deleted, I've usually got a program that does everything the old one does and more, but it is smaller, simpler and cleaner.
Most of the subtle features and knowledge embedded in the old code is not lost by using this approach; it gets pulled back in.
And...
d00d!!! Why did they have to do Windows 95? Windows 3.11 was perfectly stable and secure.
What the hell is this guy thinking? There's usually a reason that people do complete rewrites: because future versions of this software will have features that would be nearly impossible to manage using the old version.
Continuing to build feature after feature in an old codebase is like building a tower on sand. And for any of you people who want to know what the effect of that is, I suggest you visit Pisa sometime.
And for those of you not willing to sacrifice security / stability / etc, wait until the new version shakes out. And realize that the world doesn't cater to your 450 MHz AMD K6-II anymore.
Dipshit.
/^[A-Z0-9._%+-]+@[A-Z0-9.-]+\.[A-Z]{2,4}$/i
There comes a time in any softwares life that a rewrite IS the correct decision.
To put it in real world terms...
If you take a single floor home and start adding floors to it, you won't ever turn it into a skyscraper. At least not one I'd ever want to be near.
If you want a skyscraper, you bull doze the house, design the skyscraper and build it.
A lot of early design decisions can really haunt you later. Like the Apache threading example in the article.
-Jerry
What you fail to grasp is that most of us make a living of that :-)
"I think this line is mostly filler"
No, you spelt damed correctly.
Well how's about congratulations to you. For what you ask? For the "Dipshit who can't catch on to a joke award". Good work.
Skipping the other obvious misinformation (WinXP being a rewrite, Netscape 4 being any good, etc), he doesn't see the value of CSS. The FONT tag sucks. Ever try using a different font in a table? Every single TD tag needs it's own FONT specifier. It sucks. What happens when you (or your client) want to change the font? What if your back-end coder and your design guru aren't one and the same?
And XML does not and was never meant to replace HTML. XML = data. HTML = presentation. Data != presentation. That's the friggin point!
This is my sig. There are many like it, but this one is mine.
Gee, this guy has it backwards. HTML is a markup language that allows you to specify how the document should look: what should be bold, italics, centered, where the pretty picture should appear, etc. HTML has never had anything to do with separating document structure from presentation.
XML, is another story.
. there used to be a sig here.....
Reinventing the wheel can result in many things:
To start:
1.) Bad software that nobody wants
2.) Better software that people want
3.) Equivalent software that competes
On top of that, a programmer doesn't have any chance of striking it big by making slight modifications to the work of others. Reinventing the whell can gain you praise, recognition, etc. (unless your product sucks in which case you get ignored). On top of that you typically learn more and improve more from starting over.
So, from a "how does it benefit me" standpoint, starting from scratch presents a better future than tweaking. And before you blame the individual/organziation that made the leap, look at the people who are buying into the new version (i.e. the product wouldn't be a problem if people didn't gravitate towards it).
The story says, in part...
"Examples include IPv4 vs IPv6, Apache, Perl, Embperl, Netscape/Mozilla, HTML and Windows"
All props to IPv4 and all, but I don't think it stands a chance against all of those put together (even with Windows on their team).
RP
In the company that I work for, we have been running our CGI "legacy" financial application for the past 8 years. After the first 4 years, it worked fine with no more problems! Scalability, memory leaks, etc., etc. were all found. The application just hums along doing its job and the users are happy.
But 4 years ago management had to jump on the J2EE bandwagon and introduce the "Java" version of our financial product. Here it is FOUR years later and our "new" Java app is still not in production because of spec changes, clustering issues, etc., etc., etc.
I kept telling them K.I.S.S., but sales said that we need the new buzzwords to get clients and everyone knows about "Java". Hell, the way I see it, every time management changes their mind, it just adds to my job security since we need to make more changes.
Another aspect that this ignores is the fact that, sometimes, code just isn't worth keeping. You write code, you learn from it, and sometimes you throw out what you've written and start over. Even if the basic architecture is still the same, rewriting code can often result in less buggy code than can be obtained by intensive debugging. You do this with your own code; surely it can be just as useful to do it to someone else's.
Hi premise seems to be that "OK is good enough". The point is, often it seems good enough until you see what a difference the improved version makes. Take Mozilla, for example. I'm not going to argue about the slowness of XUL - there are lean, fast Gecko-based browsers (Firebird, Galeon etc.) - but I do beg to differ with the rest of what he says. Yes, you may be advised to write a stylesheet now, but you only have to do it once for your entire website. That's, what, a couple of hours' work? The beauty is, you get that time back and then some. Every time you want to change your site's look you just alter the stylesheet. Bang! All pages updated as if by magic. And you don't even have to use them. It may be deprecated, but Mozilla hasn't stopped rendering all those old, crappy websites that he professes to like. (Though you can force it not to render <blink> - this is a feature ;-))
All those little kluges: yes, they're important, but they could almost certainly have been written better if they'd been planned from the start. A re-write gives you the chance to do that.
In short, yes, sometimes it is worth starting again. After all, if it does all go wrong there's always the old version to fall back on.
"'I pass the test,' she said. 'I will diminish, and go into the West, and remain Galadriel.'"
- JRR Tolkien.
Anyone who uses Netscape 4 out of his or her own volition is either computer illiterate or really stupid.
And I think this article demonstrates both attributes. What a load of garbage.
There is a very strong case to be made against rewrites, but not by this dolt.
Buckle your ROFL belt, we're in for some LOLs.
Rewriting unnecessarily is really a symptom of a much bigger problem: failure to avoid complexity - particularly when the rewrite only serves to bloat the code base with bells and whistles.
The interesting thing about this is that developers have this ingrained sense of process that is inflexible, in many cases, disallowing the possibility of any other way. Additionally, businesses that market software have a tendency to use new features (which require constant rewrites) as a product differentiator - in order to sell more units (who cares if it works or not?)
However, there is at least one good reason to rewrite: when the rewrite will lower the level of complexity significantly enough to gain overwhelming benefits in terms of efficiency, maintainability, stability, and reduction of the number of tests required to validate the application.
Lodragan Draoidh
The more you explain it, the more I don't understand it. - Mark Twain
Rewrites can be good or bad depending on the goal and the understanding of the people doing them.
For a good rewrite to occur the following need to be true:
- emphasis on smaller/simpler code, NOT adding new features (new features may come about "for free" as part of the new design, but must not be added in as extras at this stage)
- the person/team doing the work should have a full understanding of the whole architecture of what is being rewritten
- full access to all the previous bugs and bugfixes to make sure the new versions addresses all these problems
- fairly complete regression testing should be available to compare the old and new versions
- reduce/simplify/refactor as much as possible; identify common patterns and eliminate the redundancy, and in so doing hopefully eliminate bugs as well
It's a pretty major chore that requires a lot of understanding and very comptenent people to head up the effort. But if done right, it's well worth the effort, because if it can maintain compatibility (or at least mostly) and greatly simplifies the source base, it will dramatically decrease the maintenance time needed in the future, and can naturally wipe out many potential bugs at the same time, reducing future debugging time.
I just realized that the entire ATM protocol is going to break down; an IPv6 address is bigger than an entire ATM cell! You won't be able to address packets anymore using ATM!
Most of the examples given needed rewrites to remain viable. It's easy to look at a package from afar and declare it "perfectly sufficient". Things look different when you have to work with a system daily. In particular, rewrites often address shortcomings in a system's capacity for extension. Just compare the number of third-party extensions available for Netscape 4.* vs. the number now available at mozdev.org for Mozilla and Firebird.
A bigger problem, to my mind, is when a half-dozen projects with the noble intention of replacing an aging kludged-up tool are started, all of which suck in different ways, and none of which learn from each other. And then they lose momentum and stagnate.
Examples? Most programmers agree that "make" is overdue for replacement, but despite many attampts (cmake, jam, cons, ant) no one has managed to come up with one that is compelling enough to catch on. CVS is a crufty mess, but none of it's potential replacements are mature enough or have the kind of widespread tool support to make much of a dent in CVS installations. And there are dozens of written-from-scratch applications which differ primarily on the GUI toolkit they are based on, which would be better apps if they incorporated the best features from all into a joint effort. My idea of the perfect browser combines features of Konqueror, Galeon, Epiphany, Firebird, and Safari.
--
CPAN rules. - Guido van Rossum
There are always ways to improve code. Much of the time you'll end up with a much smaller, much more efficient, much more extensible application.
Rewriting is almost always a good thing. The rules of writing english papers apply here.
At a certain point, certain portions will mature to the point that they can't or needn't be improved with each successive version. If you're content with the architecture, you'll reach this stage. But not many applications can evolve to new heights with the same diagram/layout it started with 5 years ago.
This is just a poor attempt to get noticed.
clifgriffin > blog
This reminds me of an article I read years ago, discussing the differences between the American and Japanese automobile designers. The American approach (at the time -- I can't speak for the current practice) was to completely redesign cars from the ground up, on a fairly frequent basis; while the Japanese always began with existing designs and looked for ways to improve them.
At the time, the Japanese were running rings around Detroit, in quality and in sales . . . .
duh, ac, the burdon is on you, loser. So you're saying you have no evidence, yet you're still insistent?
-M
I don't think this author understands the Internet architecture, nor IPv6's design goals. Perhaps he should before he critiques it.
Here are the essential URLs :
RFC 1958 - Architectural Principles of the Internet The end-to-end argument demands that all communicating devices each have a unique network layer address.
RFC 1752 - The Recommendation for the IP Next Generation Protocol The design goals of IPv6, including a critque of the proposals for it, including TUBA - TCP and UDP with Bigger Addresses.
He may also be interested in learning why NAT is not so "perfect" or even "good enough" solution :
RFC 2993 - Architectural Implications of NAT
Things that NATs break
Some people say there is nothing wrong with NAT. To them, I'd propose the following analogy.
Imagine you had only ever seen the world through empty toilet rolls - ie. without your peripheral vision. If that is all you knew, that is as good as you'd think the world was. IPv6, restoring full and unique device addressing, restores the Internet's "peripheral vision" - it removes the Internet's empty toilet rolls.
We may have already missed out on the next "killer app" after the WWW, as it required unique, end-to-end addressing, and the prevalance of NAT prevented it from being deployed.
The Internet's nature is peer to peer - 20050301_cs_profs.pdf
Windows XP is NT 5.1 -- (check with ver if you want) Windows 2000 with the PlaySkool OS look.
If you're running Windows XP and IE, you can check this. I don't know if this works with Mozilla. Put the following in IE's address bar:
javascript: alert(navigator.appVersion)
It'll return your browser and OS version. Mine came up as:
4.0 (compatible; MSIE 6.0; Windows NT 5.1; iOpus-I-M)
It's really common to build something, step back, examine its warts, and start over again with a new perspective and understanding. It's called prototyping. Some people actually build the first one with the intent of throwing it away. Others release it as v1.0, and introduce issues of the kind this author is referring to.
There are many reasons you might prefer a rewrite. The main one, to me, is that complicated applications contain layers and dependencies, not all of which are obvious to a new programmer. If, after some analysis, your assumptions about these dependencies are wrong, you'll break the original code faster than you can say "global variable". In the end, you could easily spend more time and effort patching and praying than you would rebuilding from the ground up.
Of course, if some of the original architects are still involved in the project, arhictectural knowledge and assumptions can be transferred to new programmers in a fairly fluid way, and I suspect it is in these cases where you can confidently add on to an existing code base.
And it's always helpful if the previous programmers were actually good programmers, and who wrote code and comments that were mindful of those who might follow them later. But that's not within your control.
I've had the fortune to be affiliated with the Icarus Verilog compiler/simulator effort over the last 3-4 years. The first version of the code had some specific design decisions that made scaling simulations beyond a thousand or so gates impossible.
The author chose to throw out his simulation engine and much of his code generation and adopt a completely new model. It took him the better part of a year to get roughtly where he was with the original code base as far as functionality is concerned. He also has a regression environment with several hundred tests he uses regularly to let him know how he is doing with respect to functionality. About 2 1/2 years into the rewrite period, Icarus is now handling behavioral code of 1 Million gates at about 80% of the performance of commercial tools!
Was the rewrite needed. YES! Did it take awhile. YES! Was it worth the wait. YES!
Have you compiled your kernel today??
Ok, so I can rewrite part of the app and he considers it ok. I can introduce just as many bugs rewriting part of something as rewriting the while thing. Not to mention royally f*&#ing up the API, and existing functions I thought that I remembered didn't touch that variable.
Then there is the issue of new tools, and techniques being available now. Better compilers, better languages, better hardware, better whatever.
If I write the original code, and I choose to rewrite, I am most certainly not abandoning history. If I didn't write it, I must have a reason for wanting to spend my time on the rewrite (better algorithm, new approach, added features, won't compile with gcc-3.0, whatever).
. there used to be a sig here.....
"Should we start from scratch, or revise existing code".
I think this conversation has happened before, and we should continue where we left off, rather than start all over again.
Version 1.3.x with GTK2 support is a complete rewrite of Galeon 1.2. I still use Galeon 1.2.10 (the last RPM released). I think to call the new one Galeon is unfair really.... as it doesn't work the same way as the old version and is missing tons of features.
Netscape's death had nothing to do with software quality or time to market.
You can not beat "free" and MS was not only giving away free IE, but setting up the entire OS to make sure you were going to use IE.
Every computer novice (the grand majority of computer users) had no real choice in the matter-- they were going to use IE.
Anyway, I think Mozilla 1.3 and greater beat the crap out of current IE. Until XP-SP2 comes out IE has no tabs, pop-up blocker, and other cool Mozilla stuff. So it looks like the Netscape rewrite did pay off.
From my producer who has also been a writer. (Apparently, Voltaire said it first.)
The perfect is the enemy of the good.
If you keep striving for the last 5% to make it absolutely perfect, you often end up throwing away what's good enough. It's not necessary for everything to be absolutely perfect. It's nice to try, but more often than not, you end up working hard for very little, and it takes much, much longer to get there.
For instance, is Linux 'perfect'? No. Is it good? Absolutely. In fact, it's more than good enough for almost everyone. Very few people need perfection out of anything they have, and it's sort of unreasonable to expect it.
Moral of the story? Don't do a code rewrite unless it's actually necessary. Things will become worse far sooner than they'll become better.
Why do rewrites happen? Quite simple. The world is changing, and it's changing in an incredible pace. We live in a world where processors double their speed roughly every 18 months. RAM gets bigger and cheaper.
What worked three years ago could be messy and clumbsy by today's standards.
The problem is: computers are getting more powerful. So the computers can do more. And computers should do more. That's why we make them in the first place. To make the life of the user easier.
Easy-of-use almost always implies complex software. It may well turn out that you can't add the required level of complexity to version N of your software, so you write version N+1.
Why IPv6? Because IPv4 isn't up to its task anymore. If you don't believe me, just ask your ISP for a /28 because your want to have all your machines online. Guys, this is a common situation and IPv4 can't deal with it! We have to use a dirty hack called NAT in order to keep things a little manageable.
Why Mozilla? Netscape 4 is slow, unstable, underfeatured. It won't meet the demands of the modern web by a long shot. It's got a poor CSS implementation, the HTML implementation is not standards compliant, XML? Nah...
In short: change is inherent to the modern (IT) world. Deal with it. If you really think netscape 4 is a good browser, it's getting time to look for a new field of interest. Seriously.
This is your sig. There are thousands more, but this one is yours.
Most software is pretty bad. It was written by not very skilled or motivated people under unfavorable conditions.
This is often taken as a reason to rewrite the system.
But what people always seem to forget, is the the rewriters are just as unskilled and unmotivated, and the conditions just as unfavorable as when the first version was written.
So, naturally, you end up with a completely new system that is just as bad as the old one.
Document all your changes, oh yeah all those 'programmers' hired in late 90s did that. When the turnover left you with buggy code and the author on the street, maintaining that crap can lead to re-writes. You can add stuff to a good base, but when the base is rotten you have to replace it.
I can think of two reasons:
1. As already pointed out, if its someone else's code that you have to maintain/enhance, it is most likely you will succumb to the rewrite temptation.
2. When the original team decides to rewrite. This happens when the team set out on a project, almost finished it and on the way discovered things they didn't know before and methods that are result of actual learning. This is what happened to many Open Source projects e.g. Mozilla, Eclipse. Refactoring overload.
I guess I am trying to say that rewrite happens for lack of knowledge/experience and too much of it!!
You silly person. He was making a joke. (Notice that he left out all his N's.) What is "adjective (-ed)" supposed to mean? "Adjective" is already an ... adjective. There's no need to stick an -ed on the end. And by putting it in brackets you just look indecisive and foolish. Or did you mean "adjectived" as a verb? That would suck badly. You can just go around verbing your nouns like that. "Interjective" is not a word, at least not until now when you made it up. "Interjective vulgar" is pure wankery. Don't say "often times". It sounds affected. "Would possible mean"? What could you possibly mean? Congratulations, you win the "lamest grammar-flame ever" award.
IP packets are not mapped one to one with ATM cells.
One arbitrary length IP packet, whose size is chosen by the source device, is mapped over the top of a number of ATM cells, using the AAL5 or ATM Adaption Layer 5 method.
The Internet's nature is peer to peer - 20050301_cs_profs.pdf
>> Sometimes writing a whole piece of software is the best
>> way to take your coding to the next level
The sad thing is, I don't see this happening. Rather than reading good code written by somebody else and learning from it, most of those notepad wannabes write their own crappy code and learn NOTHING. It's like learning languages. To learn to speak well you have to be using the language in your conversations with the native speakers for hours every day. It simply doesn't work any other way. Same here. In order to accumulate the knowledge you have to have some kind of source of this knowledge, be it an experienced developer who's mentoring you or reading somebody else's code, or having your own code reviewed and criticized by your peers.
There are 16.7 million addresses per square metre of the earth's surface, including the oceans. This is overkill. The world does not need more than the 4 billion addresses available with IPv4, and I challenge you to come up with an application that requires that many.
Smart Dust .
Da Blog
No, thanks. I'll stick with Frederik Brooks' "Plan to throw one away, you will anyway".
50 years of wisdom are not to be discarded lightly.
But, then again, perhaps because people have forgotten this rule we've been stuck with the same OS design for the past 30 years -- people keep adding to it without really understanding the problem. On the other hand the new developments are shunned and soon forgotten.
System software research is irrelevant.
Go ahead, reuse the same code over and over again until it becomes a bloated behemoth which nobody understands, contrary to what are probably the three best rules of software development -- Simplicity, Clarity, Generality.
They should teach kids at school that as soon as they have understood the problem they should rewrite their code to reflect the fact.
I hate to say it but there's a lot of code out there that isn't so much badly written as it is badly documented. Why some programmers think it's k00l to write undocumented code is a testimonial to their egotism, insecurity and selfishness.
I also contend more rewrites have been done by the original developers because they were too lazy to remember and document what they were originally doing.
There's nothing wrong with rewrites. The whole goal of a rewrite is to learn from the first few iterations of an application and improve upon it. I'd also contend that it's just as easy to introduce more bugs by modifying existing code, so this argument is basically a rationalization to excuse poor programming skills.
The author missed the boat in this case. I suggest he do some reading on web standards; the font tag is deprecated because a) It has no structural meaning b) It is a pain in the ass to update a hundred font tags when you can use a single line of CSS c) It wastes space. d) It mixes style and content.
The author says "The Web exploded because it was opn and simple - accessible to schoolkids, anybody could write their own web page".
No, they couldn't. They could write invalid crap markup that most browsers would forgive, but very few actually wrote correct web pages. We are moving towards portable devices with less CPU power to waste on guesstimating what your invalid markup means. This is where XHTML comes into play. Your markup is valid or it isn't. If it's not valid, it doesn't display. End of story. Programmers have been dealing with it for 50 years. It's time web developers upped their standards.
MS SQL 7 was a complete rewrite, and it rocked compared to 6.5.
This guy obviously can't get around the fact that bad designs are bad designs. He gives some good examples (embperl, for example), but then goes right downhill with his harrasment of Mozilla, and hits rock bottom when addressing HTML.
Mozilla is two thing, a rendering engine (gecko), and then the application suite. That he can't see his head around that is a bit irritating, but hey, it's his opinion. Still, firebird's faster rendering of XUL, and ridding itself of extranios code would most likely suit him better, but he simply doesn't address it.
As I said, his HTML vs XML and associated standards analasys is fatally flawed, as I'm sure many of you know. If you don't, check out a list apart (http://www.alistapart.com/), the folks there cover the ins and outs of the need to redesign html much better than I could.
The fact that he starts with "The Web was based on the idea that a simple markup language could allow us to divorce document presentation from document structure, and concentrate on how information was related rather than how it should be displayed." and then goes on to describe how <FONT> tags aren't that bad, obviously means he's missed the whole point.
And <FONT> tags are depricated in HTML 4.01 strict as well.
Please, before posting a huge flame doc as an article, please do your research. We are geeks after all.
Oh, and yes, I did just pick and choose which I read, thank you very much. I don't have enough info on the background of the rest to have an informed opinion. I personally find there to be a great deal of merit in that.
This is another "my favorite color is blue" article. There are reasons to rewrite as opposed to patch old code. It is never black and white. Some features work well while others need work. Porting solid code that is mission critical is a good idea, but if you are adding support for a new file system (or something similar) then a rewrite that is more optimized to the new requirements is the better alturnative. Sure there are tweaks and bug fixes in existing code but there are also hacks and work arounds, if the new code is based on the old and diverges in code that wasn't effiecent then thats good and improves the quality and stability of the system. If its getting rewitten "just because I felt like it" then its a bad idea and should be avoided. So it entirely matters how stable and maintainable the old code is and what level of modification is required for new features. The old code may be stable but horribly ineffiencent and great performance gains maybe realized after the rewrite. They just isn't any simple answer to this issue it just depends!
It's easy to look into the past and say "this and that" should have been done.
But what about current programs...
A few key people recently left the XFree effort seemingly because they felt a rewrite was needed.
What do people who know something about XFree code think about that?
WinXP was not a "rewrite" at all- in fact most people call it Win2k with some fancy pretty GUI stuff.
And IPV4 VS IPV6?
Huh?
a) that's not software
b) he refers to "poor applications knowing 32bit addresses, but being forced to deal with 128bit addresses" - that's ridiculous- the OS deals with that in most cases.
c) regardless, that is *not* the reason IPV6 has gone nowhere- it's because simply of no backwards compatibility. the idiots who planned it astoundingly imagined everyone in the world simultaneously turning off their IPV4 devices, and turning them back on as IPV6.
I browse at +5 Flamebait- moderation for all or moderation for none.
If changing the original (but preserving the purported API) causes potential massive breakage then a re-write is required as there are obviously untoward side-effects involved and/or indecent coupling from other code bodies. The breakage is a clue on what was broken all along. That it worked under some constraints sort of well enough does not mean it was healthy or wise to leave in its original state.
It all makes sense now. Article was written by a web DEVELOPER. Some of it came close to making sense, I can certainly see why new APIs can be frustrating, and the point is valid in certain cases, but I didn't see any in the article. The point for me isn't that rebuilding is bad, just that it isn't always good - making the choice is the right tact, not "don't do it". Have fun with your HTML programming!
Why rewrite?
In open source, its mostly because you can. There are usually NO deadlines, so the rewrite can occur on the author(s) timeline. In a corporation this is less likely and more difficult.
In the case of mozilla / netscape, the thought was that netscape was 4 years old or more ( I can't remember ). The UNIX codebase was based on motif, and not sure what the windows codebase was, probably VC++. The problem here was that the goals were to large. The new developers did not want to use much of the old code base as I imagine it was ugly, so they rewrote from scratch. The problem they ran into is that this took them about 3 years to get a product to market that is now (4 years or more later) a great browser, but maybe a little to late to market.
IMHO they should have picked subsystems to rewite and worked on that instead. Not sure if they could have, but maybe they could have just changed the parse or the UI first and then worked on the rest later. Maybe a port to QT or something else would have been better and then to have released that as 5.0 and worked on bugs and new elements. Then the 6.0 could have been fixing the parser. That's my opinion, but not sure they could have.
Gtk+ had similar problems and they rewrote much between 1x and 2.x.
Most of the time the rewrite occurs, because times change. Needs change and things change. A codebase becomes outdated and no longer functions well. This is likely what happened with netscape. It was no longer useful to keep the codebase.
Also you have developers that disagree on the best way to do things and it is difficult to get motivated to update and maintain someone elses code if it is crap code. So they rewrite.
I wish I had that luxury here where I work, as I would love to rewrite. Problem is that we have deadlines and clients that we cannot just rewrite stuff anytime we want.
I think the rewrite occur mostly because they can, and because noone wants to maintain someone elses code. They want to leave their mark on society so to speak and it becomes their code.
Only 'flamers' flame!
Does slashdot hate my posts?
How is it possible to so completely miss the point of Perl 6? The intent is not necessarily to replace Perl 5 - Perl 5 is fantastic and the Perl 6 developers above all people know this. Perl 6 is perhaps best thought of as a DIFFERENT LANGUAGE which will 'just happen' to be, in many places, very similar/identical to Perl 6.
Once you start thinking of Perl 6 in that manner, you realise what it's for. It's not to replace all of the Perl already out there. It's to provide a new tool, a new language for doing new things in, drawing on the experience gained in years of working with Perl 5 and other languages.
Ponie, of course, is part of the effort to make sure that at least some of the vast amounts of Perl 5 code is usable with Perl 6, should programmers wish it. And even that's not a total rewrite of the existing Perl codebase.
So ultimately, that article has nothing of use in it. Yes, programmers should be careful what they rewrite and when they rewrite it, but many times such things are actually worth it. GTK+ 2, anybody?
Miri it is whil Linux ilast...
not to be picky or anything...but that 16,700,000,000 per square meter comment is waaaaaaaaaaaaaaaaaaaaaaaay off....
it approximatly 2,200,000,000,000,000,000,000 per centimeter
I completely agree with the code re=written comment though. With all of the provision in IPv6 such as IPv4 Compatible, and IPv4 Mapped IPv6 addresses, there is really no need to re write any code, you can simply put an additional NIC in the machine that is configured for IPv4 and the IPv6 router will handle encapsulating these packets. What alot of people don't realize is that the first 32bits of the new IPv6 address space has been reserved for existing IPv4 addresses.
As for the absurdlyl huge address space. A lot of it is reserved and most of it is unallocated for any specific purpose, leaving lots of room for IPv6 to grow.
One more point on over all performance of IPv6: Only the source and destination node may fragment a packet. This will reduce the overhead on internet routers because they will no longer need to be concerned with peicing together fragments created by another router just to get the original packet in a readable format.
If you must!
For instance: Mozilla was a rewrite of the Netscape code base, but Firebird was able to leverage the new code with out rewriting it again. This says to me that the developers did it right the second time around. Is that really so bad?
I've been programming long enough to remember when Perl 4 was state of the art. The same thing happened when we converted from version 4 to 5.
Remember the big changes in Perl 5? We got objects. We got a standard way to extend the language. I remember having to re-compile perl into oraperl in order to connect to a database. Now I don't need to.
The point is that there are major changes in technology that you need to support and the best way to do that sometimes is with a re-write.
Generally, the following rule applies: When a major technology is not supported by the current software you should consider a re-write. this means that when you add something big like: threading, distributed objects, multiple platforms, etc. you should look at your options. Many times the right call is a re-write.
I support the work they did on Perl 4 to Perl 5. They get the benifit of the doubt for Perl 5 to 6. Their judgement has been proven right before.
This whole article is just fucking flamebait. This whole fucking site is nothing more than Linux propaganda vehicle.
FUCK YOU SLASHDOT YOU PIECE OF SHIT.
I will be trying to do something a certain way, that I would do with certain pieces, but then, I can't find the pieces, and I take an alternative approach.
And then, later, when I find the pieces I wanted to use originally, I realise that the method I used as an alternative was much better!
I love NetHack.
cue
<voice style="character: Andy Rooney;">
Didcha ever notice how sometimes
they write code that is supposed
to be better?
Better than what?!?!
</voice>
Toddlers are the stormtroopers of the Lord of Entropy.
seems common in other areas of engineering also, bridges could just be retrofitted, buildings added on to, but sometimes there are too many unknowns in engineering old structures... Are the building materials made from Asbestos, How has the structure held up after so many years? Have other modifications extended or complicated further modifications beyond that which the original plans called for? Sometimes the unknowns themselves justify building from scratch. Sure we could just keep tacking on new technologies to old, but the result will seldom be better. More often the real advancement comes from taking the knowledge gained from past experiences and applying them to new, rather than actually taking old work and trying to make it work in a new situation.
Would you really want horses running on a treadmill attached to the front of your car, just because humanity wouldn't want to throw away its previous investment in transportation technology?
One thing for sure - the old server is performing nicely under the load. I put in a front-end reverse proxy (apache + mod_proxy) a while back to improve performance, and it seems to be very effective. The server is still responsive under the load, and no problems at all so far.
;-)
Well, apart from the odd flame here and there...
Well, it was professionally written, except for the use of phrases and words like "pain in the ass", "jackass", and "asshole".
There are 0x40000000 types of people: those who understand 32-bit IEEE 754 floating point, and those who don't.
I've yet to see why a rewrite is a bad thing.
die "Need argument containing valid directory" unless $loc = $ARGV[0];
[...]
@dir = split(/\n/,$dir);
unshift(@dir, $loc);
$dir = join("\t",@dir);
The fact that I can write code like I do above is a "bad thing". As much as I love the "unless" command, it's bad code. As much as I assign mutually exclusive variables to @dir and $dir, it should not be done, especially when $dir and $dir[0] contain two wildy different items.
I suggest you have a read of this book, as it identifies the motivations behind a number of the design decisions behind IPv6.
For example, IPv6 addresses were originally 64 bits in size. However, to facilitate autoconfiguration of node addresses, based on their EUI-64 link layer address, the decision was made to increase the IPv6 address to 128 bits.
IPv6: The New Internet Protocol (2nd Edition)
A fair amount of the content is mostly regurgitated RFC details. Those RFCs are now obscelete. The value in the book though is the commentary on the design decisions, and the "points of controversy" in each area. The only other way to learn about that would be to read through all the IPng / IPv6 mailing list archives, and that would take a lot, lot longer than reading this book.
The Internet's nature is peer to peer - 20050301_cs_profs.pdf
License.
I've rewritten a lot of code from the sepcifications to get out from under the license.
I've rewritten commercial code to get out from under the commercial license, and I've rewritten GNU code to get out from under he GPL.
Unless everyone suddenly goes to a BSD license (or public domain, which leaves them open to legal liability, for lack of a "hold harmless" clause), I expect to be happily hacking away for many, many years to come.
A wise friend of mine, who's been in the software/hardware business for a long time, has a saying:
"Designs are like waffles -- you throw out the first couple."
Many people make the mistake of continuing to work with an old design (read: software implimentation), tweaking it, hacking on it, etc., for fear that a rewrite will take too long, be too expensive, or never work as well.
That's why, for example, IOS is such a mess, IBM still develops in PL/X, there are so many COBOL programs still in use, and the bloody x86 instruction set still has yet to be abandoned for something more sensical.
Rewriting a module, component, or entire product gives one a chance to learn from one's mistakes the prior go-around, make the code more maintainable, stable, and secure, and generally do a better job.
I agree that following this procedure will undoubtedly introduce new bugs -- such is a fact of life. But all software has bugs -- some of them were coded last week and some of them were coded 20 years ago. To insist that users continue to utilize an old, outmoded, poor, or otherwise deficient design or implimentation is not acceptible and, IMHO, ends up costing more time and money in terms of sustaining development and support.
The point that a total rewrite loses all the little tweaks over time is well taken.
However, it also loses all the little hacks to make things work, particularly ones from bad design due to not fully understanding the problem the first time around.
Most code for anything substantial has at least one major design flaw the first time around that's often possible to work around, but extremely difficult to fix. A major rewrite to a more appropriate solution (like better data structures) can often simplify code substantially and reduce hard to find bugs.
But if that's not the case, resist. There's sometimes the urge to rewrite something because it's old, or difficult to understand. Unless your solution is much easier to work with or solves some actual problem, it's very risky.
-- Kate
Having done this for years, I think I'm starting to figure out why I do it, and perhaps someday I'll be able to stop myself from doing it, so that I can actually release something :-)
I think the need to rewrite is more emotional than intellectual. As I work on an existing codebase, I notice the little bumps and warts on it, the little "tweaks and fixes" which make it work, and I find them ugly. For some reason, I place the highest aesthetic value on code that was written in one big, flowing session, where the entire structure was understood from the beginning, and the entire thing looks like it was born fully-formed from some supernatural source.
In an ever futile attempt to realize this goal, I constantly chuck out perfectly good code and redo it from scratch. I do this because I seek the emotional experience of those few times when I really do sit down and blast out something that's beautiful, elegant, and functional. Even if, practically, it's no better than before.
Open source programming is often described as scratching an itch. It should be immediately apparent why this correlates to extensive rewriting of code. Some problems are simply enjoyable to solve. The necessary thinking feels good. Just as we watch a good movie again and again even though we've got the plot memorized, some programmers want to rewrite the same functionality repeatedly because it just feels good.
To hell with practical considerations, like whether or not that's "bad" for the codebase. I program for pleasure.
First of all, not all of these "rewrites" are actual rewrites. Win2k was not rewritten to produce XP.
The HTML example he gives is self-contradictory. He writes positively about separation of content and presentation, then whines about CSS separating content and presentation.
The Netscae 4 codebase was better than 3, but it sucks compared to anything else people use today. Mozilla may take longer, but nested tables can freeze Netscape for minutes or hours.
If you think XUL's a problem, use Galeon, fer crying out loud.
You know what the worst part is? I agree with him. There are very few necessary rewrites. It's just a matter of knowing where you want to end up, and then figuring out how to get there from where you are. Doing it in stages means that you're never stuck with unready code, and most of it is well-tested by the time you're finished.
Is that the guy from "Life goes on", Corky? Man he is in IT now too? WHOA!!!!!
'"Considered Harmful" is Considered Harmful' is Considered Harmful.
Most of those examples are bad examples, because several of them aren't the results of total rewrites.
I have a 400 MHz PC at home. Netscape 4.7 runs acceptable fast. Mozilla is a hog. So I'm sticking with Netscape 4.7.
It's also useful to have that browser around when doing web development, to ensure that my sites look OK in the older browsers. There are still a lot of Netscape 4.7 browsers floating around out there.
That said, I use Mozilla on both my 1.8 GHz laptop and my 2.0 GHz work PC.
Like woodworking? Build your own picture frames.
> But you have to consider what Netscape would be like if it had had the amount of work put into it that mozilla has now.
If you knew the history of the Mozilla project, you would know that modifiying the old Netscape code would have gone nowhere.
Before the Mozilla developers decided that a rewrite was necessary, they spent the better part of a year trying to improve the original Netscape code.
But the code was so bad that they couldn't attract any developers -- no one was willing to work on it.
Trying to work on the old code was boring, and difficult, and required huge amounts of effort for very little gain. Also, the code was not modularized properly, which meant that very few developers could work on it at the same time without constantly tripping over each other.
If they had simply tried to upgrade the old code, you would have a slightly better Netscape browser today (assuming they didn't give up entirely).
But the rewrite attracted large numbers of developers, and produced some real innovations.
Today, Mozilla is a much better browser -- head and shoulders above IE -- with better stability, better standards support, and features such as tabbed browsing, and pop-up blocking.
But more than that, the Mozilla project has given us a powerful cross-platform development toolkit, with the XUL user-interface facility. This has not only created a new field in developing Mozilla plug-ins, but is being used for the construction of many other products.
The original poster was right. The author of the article is talking nonsense.
Netscape, and the web, with each version since at least 2 or 3, became less usable. In the days of Netscape 2/3, it was stable. The HTML standard was a lot simpler, and it was standards-compliant. I remember those days. The web worked great. It was faster than it is today, more machine-parsable, more disabled-friendly, easier to make web pages for, and just generally better.
The problem came in when web design weenies decided they want pixel-by-pixel control of where everything went. Netscape and Microsoft, in competition to embrace-and-extend each other out of business, added crappy extensions to allow this. We saw layers, JavaScript, Java, Flash, etc. come out around this period.
In order to keep up, the W3C came our with hairy standards to allow web pages to describe this sort of stuff. Writing a web client went from several months, to many, many years, with the only added benefit of web pages looking a little bit prettier with a good graphic designer, and much uglier and less useable the other 95% of the time. On the other hand, modern web pages now consistently cause the masses of complexity called web browsers to crash (I use Netscape, Galeon and Mozilla -- all of them consistently crash). Due to the complexity of the standards, different web browsers support different subsets of the standards, and so render differently. Web designers usually only sit with one or at most two browsers, and so never see how the pages break on everything else. Heck, with a lot of web pages, having a different set of fonts or different font-sizes from the web designer's box causes it to render uselessly.
Normal people no longer learn HTML -- it is now much more complex than languages like TeX. They use tools like FrontPage, but increasingly the web becomes asymetric, with content providers (big companies with web design teams), and content receivers (typical end-users, overwealmed by the web, and only capable of putting up very crude web pages).
I really don't see any win here. We introduced shitty standards, and coded shittier software to run on those standards, and then whine about how the old software isn't compatible with the new standards.
FINALLY.
That alone was enough to make me upgrade.
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
Something that he seems to be forgetting is that just because a piece of software goes through a significant rewrite or re-engineering, doesn't mean that the previous version isn't still usable.
Sometimes I do use software that "just works" that is a few versions behind. But that doesn't mean I object to people improving it or rewriting it. Sometimes it just has to to with which version you prefer.
I mean, XP and 2003 have less security holes, not more. If XP gets it, dollars to donuts 2000 has it too (with few exceptions, notably UPnP).
All of his opinions are as shallow and uninformed. He just sounds like someone whining about change, only looking at the downside, and not even attempting to realize the potential benefits.
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
I seem to remember the person in charge of developing Internet Explorer for MS saying this *exact* same thing. In fact, he claimed this was the reason MS won the browser war: Netscape lost all their years of work because they decided to re-write their browser, while IE tweaked theirs. I'm sure I read this on /. somewhere, but I can't find the article.
:(
I know a lot of it had to do with MS's business tactics, but Netscape/AOL took like 5 years to put out a new browser after 4.7. And do you guys even remember Netscape 6 Preview? What a god-awful browser that was. My friends starting calling it Nutscrape cuz it was so painful to use
I was taking him seriously until he mentioned he used netscape 4 as his main browser. This can not be anything other than a troll (hmmm, moderation system must be working if they're submitting stories now). I run mozilla firebird, reasonably fast, on a pII/233. It's faster than netscape 4 on the same hardware.
The reality is netscape 4's engine was too broken to be fixed. The lacking DOM and CSS support in NS4 was not because they didn't want to add it, but because they couldn't add it. The engine HAD to be rewritten, and ofcourse, one thing led to another, and it was deemed wise to rewrite pretty much the whole thing. Which imho was a good decision, because firebird beats ANY other browser easily.
Polishing and fixing bugs in a GUI toolkit takes a lot of time. Accessibility usually gets left behind.
For an example of all the work to get widgets right, just on Windows see the Accessible Toolkit Checklist
> what is wrong with rewriting the code from the ground-up?
Nothing is wrong with that, as long as your time is worth nothing.
Actually, rewrites can actually save time if the code is old and crufty enough. Cut-and-paste programming, fragile global dependencies, poor or non-existent factoring and other antipatterns can make a code base all-but unmaintainable.
Unfortunately, it's very hard to determine just when your code has become so hard to maintain that a rewrite would actually save time over hacking in needed new features. My experience suggests that keeping old code alive for too long is the more common error, but there are plenty who err the other way too.
Those instances of Slashdotter are not necessarily the same person. Furthermore, Microsoft would be totally braindead to make a business plan from Slashdot comments. BillG probably isn't that dumb, despite what we wish for ;-)
__CmdrTHAC0__
In Soviet Russia, Spanish Inquisition doesn't expect YOU!!
So you're saying you have no evidence, yet you're still insistent?
Oh, that's nothing new. . . I've spent the last four and a half years of my life in Alabama, so I'm used to it. :)
!#@%*)anks for hanging up the phone, dear.
If all you're browsing are pages served from a single domain, consisting primarily of flowed elements (headers, lists, images, and that's about it) with pages that are fairly short.
Start adding tables and forms, trying to reflow the page when resizing (especially if it's a long one), and prepare for the wait of your lifetime.
At least mozilla can display part of a page while the rest renders, and resolve more than one domain name at a time when connecting to resources in parallel.
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
Win 95 sure did work flawlessly. It was a bummer when 98 came out. My BSOD went through the roof from 5/day to 30/day.
I usually find Jamie Zawinski to be an arrogant rude asshole, but occasionally our opinions overlap. In this brief rant he describes the Cascade of Attention-Deficit Teenagers software development model, which often leads to rewriting code from the ground up. Over and over and over.
Stay out of that trap, and actually fix stuff during your rewrite, and there's nothing at all wrong with doing it over from scratch. Rewrite it just because you don't feel that modifying other people's code is sexy enough, or that your version will surely be bug-free -- because, hey, it's you -- or because "you would have done things differently," and you'll have failed.
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
what the hell was wrong with XMMS? I mean seriously, the plugin architecture was ass-simple. It wasn't fancy visuals-wise but it ran on damn near every Unix with that could support an ATI rage card.
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
Like almost everyone here, I'm a developer and have an opionion..
Anyway, it seems to me that this is all a point of discipline, or more specifically, lack thereof.
For some reason (which is probably best another thread), Software Engineering has lost the 'Engineering' aspect and become, well, just Software. This is _not_ good.
Take any engineering discipline out there, and think of _how_ projects are done. There are standard ways of conveying ideas, standards in diagrams, and in many cases, standards in documentation (though they may be loose). Any sufficiently accomplished EE can look at a schematic from any other and tell you what it is (understanding what's presented is a different story, but they will at least be able to _read_ it).
Software is.. well, just code.
At our company, we have a development process that was invented by our head honcho (read: founder, CTO, etc). It covers everything from documentation to code formatting to testing process. By using it, we've achieved a good codebase (over 1500 functions in the core libraries that can be accessed from any product/project) and have been using it for years. Likewise, anyone can look at code from anyone else, and it looks the same. You'd be amazed how much of a difference it makes.
Granted, we are a "small" company, so the same may not work for everyone (read: two people with sufficiently sized egos butting heads over the 'correct' way to code), but by using engineering instead of coding by the seat of our pants, it works.
I'll also say that we've had to do a few re-writes. Mostly, it's caused by engineers who have 'left' and weren't following convention or by new people who were still getting the hang of it. The code is impossible to follow, since documentation is the ugly bastard stepchild of software, and they didn't follow the conventions (e.g., someone using a 'standard' variable for a loop counter just because it was already defined). It's a mess, and it does need to be re-written. Basically, you just need to look at the additional time it will take you to support/improve the project 'as-is' vs. what a re-write will cost (often times, just re-writing modules is good enough, a thread here or there over time and it'll end up the way you want it to). Along those lines, there are several ways of doing re-writes; and some are better than others. If you go off into a box and design a new version of the same software, have the decency to name it something else. A re-write involves looking at the old documentation (if it's good, if not, it's off into the software), maintaining some semblance of backwards compatability, etc.
Well, that rant got a bit longer than intended. Ah, well. Bring engineering back into software development, and it will be a huge boon for the industry... or, we can just keep on re-inventing the wheel.
I've often thougth the same thing hundreds of times!!!
I first started programming on a C64. Moved on to Unix shell scripts, C, Python and a few other languages. Most all of my programs are simple and straight-forward and they work! However over the years, I've received many suggestions on rewrites because my code didn't make x,y or z into a function or a class and we all know that functions or classes would be sexier in this situation.
Or, I've heard things like, "That's great, and it's really simple and elegant, but it's not characteristic/ideal C code so we should re-write it to be more like the new x,y or z approach." To me, that's BS. If it ain't broke, then don't fix it. Most of the comments I've gotten like this come from PhD's in CS. They spend inordinate amounts of time thinking up the ideal way to use a language or design programs... to them a simple, easy solution that works isn't very sexy, certainly not interesting... maybe that's why they're always doing rewrites adding classes to languages adding OO capabilities to everyting, etc.
All this reminds me of a friend of mine who is starting to use Linux... he works on building kernels and attempting to configure x,y or z more than he actually uses the computer. This is OK to a point, but after awhile it becomes tedious.
A particular technology has a lifetime - and just because a piece of software uses it, and there's now something better, doesn't necessarily mean that it should be rewritten. If the piece of software is crap then it shoud be rewritten (so this is case 1). Case 2 is when you have a good piece of software that is using a technology that is at end-of-life. People should resist the temptation to rewrite in the case that the software is well written but is using slightly old technology (but one that isn't yet end-of-lifed).
Half of the things here aren't rewrites. Apache wasn't rewritten, just changed API-wise. Of course the old version works fine, unless you are a developer, in which case you feel like you're getting ripped apart by your anus in the 8th circle of Dante's Inferno. Windows XP was merely a revision, and although it is in some sense a rewrite of Windows 95/98/ME since it comes from the NT family, it is certainly not new code. IPv6 is only subjectively a rewrite of IPv4, more accurately a revision. Mozilla shares code with Netscape 4.8, although XUL is new.
I think this is more of a complaint about any upgrade that breaks compatibility than a complaint about rewrites.
Honestly folks, how many of us have written a program that we are entirely satisfied with? That wouldn't benefit from a careful rewrite from first principles?
In the real world, it is true that we must balance what is gained with potential losses. The addition of new features and the removal of new bugs is often costly. Depending on what the value to the users may be, this may make the rewrite an economically infeasible choice. But few programs are so simple and limited that they couldn't benefit from another try.
Any program worth writing is probably worth rewriting.
There is much pleasure to be gained in useless knowledge.
Another great example not mentioned by anyone yet is the excellent Opera Internet browser. It isn't always rewritten from scratch, but overall there are enough changes in each new major version to make it almost unusable, at least to me. Every time a new version (3.0, 5.0, 6.0, 7.0) is rolled out, many little things no longer work as they did, and sometimes they are clearly and unequivocally broken.
:)
Before I knew better, I used to download the release versions (not betas or RCs), but each and every time I ended up uninstalling the new version and switching back. It usually took more than a month and about 10 updates for a new version to reach relative maturity. Witness 3.21, 6.05, 7.20, only these versions could be considered better than their predecessors in all respects. With version 7 I succumbed at about 7.1, but next time I will really know better and not even consider Opera 8, until there have been a month without updates.
On a more serious note, I think there is moment of maturity in many every product's lifetime, a moment when new features could no longer justify an upgrade (other things, such as compatibility, being equal).
Future Wiki -- If you don't think about the future, you cannot have one.
Thinking that somehow XML is a rewrite of HTML shows his general lack of knowledge here. I mean, doh. XML is not a language meant for browsers or displaying nice pages, it's a way to structurate data. XML uses HTML/XHTML though for it's representation, so it can be used for that, it's just a side use. Now, stroring/transmitting/fetching structured data... that's what XML is about.
And CSS? Just don't get me started on how silly his idea that plain old HTML is better for large complicated sites than one CSS file to rule them all pages. Yeah, it's sure easier to maintain all the pages' layout by rewiriting every single page to match the new look.
Some people...
___
*insert sig here*
Any experienced developer, without an ego, will know that leveraging existing code is usually the best way to get something done faster and better. The Mozilla rewrite was a terrible idea and is what resulted in its delay. Sure, Netscape code might have been aweful, but incremental improvements are usually better.
Another thing that one can do to justify /etc/wtmp -> /usr/wtmp -> /var/log/wtmp.
one's existence is to rename files,
like conf.modules modules.conf,
or
This is much easier than rewriting code
and every bit as disruptive.
How come Linux wasn't included on that list.
Besides Linux itself being a rewrite of an old UNIX system, within Linux there are examples of rewrites for no good purpose. One example is the Linux TCP/IP stack. Almost every other OS under the sun uses the BSD codebase as their starting point, so all machines that talk together on the net speak through a common codebase. Linus, for arbitrary reasons nobody has fully explained, decided 'he didn't like' the Berkeley stack, so Linux adopted a rewrite. This means that there are warts and features on the Linux stack, that everbody else has to work around.
The sad note is that in spite of this, Linux didn't get prominent listning in the article summary on the slashdot page. Any particular reason, Rob? It makes you look bad.
It's time web developers upped their standards.
No kidding. To quote Pat Paulsen "We've upped our standards. So up yours."
* And remember, it's spelled N-e-t-s-c-a-p-e, but it's pronounced "Mozilla."
While, for example, BSD's 'ls' program can be tracked all the way to the seventies, GNU people of course rewrote it just for the license sake.
A nice example is the 'ping' tool. The story of ping tells how the program was concieved and made, and the FreeBSD's current ping.c is based on it:
That's a codebase 21 years old and still viable!-- Sig down
Actually, most people I have seen creating their web pages have been using WYSIWYG tools. I have a few friends who like myself like to get back to basics and craft the markup themselves, but most of the people I know still use WYSPRWYVWS (What You See Probably Resembles What Your Visitor Will See) tools - one of them just recently said, when I pointed out that a small web page had a dozen-or-so errors when run through the W3C validator, that "yeah?". "So does www.${big_computer_company}.com on their front page."
The problem is laziness, not lack of ability. I use XHTML 1.1 these days, and check to make sure the pages I create are valid. I also check how they appear in text only browsers (using Lynx), and make sure that the content is accessible to such users as well. (Obviously images and more advanced formatting is a different matter, but a <h1> is always a <h1>.) If people creating content for the web in general would go through half the trouble, a lot of pain and unnecessary guessing code could probably be weed out from the web browsers, not just Mozilla (or technically, Gecko). And yes, WYSIWYG tools should be capable of creating standards-compliant HTML, too.
Neither does hand-crafting HTML have to be hard, or divert attention much from the content. Especially not if you have a decently designed CSS style sheet. I personally find it a lot easier and more intuitive to write
than to click through half a dozen dialog boxes to do the same thing (insert a right-justified floating image). Most web sites have a standard basic outline, but you never hear people complain that it diverts attention from the content (if it does, they need to think about what can be done to it), and HTML code is little different. There is a header, the content, and a footer. The lion's share of just about any properly written HTML/XHTML document is going to be the content. So where is the big difference? Writing the tags myself also gives me a moment in between paragraphs to reflect over the content, which can hardly be considered a bad thing.This will probably get modded -1 flamebait, but I'll take the chance.
Been modded interesting, insightful and funny. Why does real life have to be so different?
That this doesn't become a new mantra amoung PHB's, "No Re-writes!" . Imagine how frustrating that would be, especially when a re-write is absolutely nescesary.
True genius is grasping a situation like a peice of fruit, and peircing it just right so that it drains dry.
n/t
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
"When I first came here, this was all swamp. Everyone said I was daft to build a castle on a swamp, but I built in all the same, just to show them. It sank into the swamp. So I built a second one. And that one sank into the swamp. So I built a third. That burned down, fell over, and then sank into the swamp. But the fourth one stayed up. And that's what you're going to get, Son, the strongest castle in all of England."
Are you talking about making them burn forever in writhing agony or making them high class eunuchs? Yeah yeah, everyone knows what you mint.
> world does not need more than the 4 billion addresses available with IPv4, and I challenge you to come up with an application that requires that many.
It's not really how many there are, it's *where* they are. And the difficulty of getting them assigned is driving people to use NAT instead, which introduces more trouble than it solves.
If you can solve the problem of allocating IPv4 according to need rather than corporate power, get everyone to use the same set of extensions adding features IPv6 has built in (IPsec, QoS, etc), and solve the routing issues behind finding addresses split up into groups of two or three IPs then maybe you have a point.
> Assuming that you can actually come up with one, it could easily be solved with Network Address Translation, or NAT as it is commonly known.
So how do you do VoIP between two users behind NAT?
How do I run a personal website on my desktop if I'm behind NAT?
Sure, IPv6 may have far more addresses than we think we need. But so did IPv4. 32 bits to hold addresses? - we're only ever going to have maybe 50 universities with seven or eight computers each on the internet!
- Muggins
I'm sure they'll protect against the greatest threats. Maybe some default security to protect microsoft?
Site blocking
-----------------
RedHat.com Block [x]
Debian.org Block [x]
Suse.com Block [x]
Slashdot.org Block [x]
Microsoft.com Block --unavailable--
I'm joking of course, but anyone remember how after installing certain updates/software from Microsoft at one time netscape would begin crashing horribly afterwards? He who controls the default firewalling settings could control a lot... he who controls a popular closed-source OS could do as lot worse
I disagree - if only because in more than a couple of instances I've seen first-hand, the gains of a rewrite were worth the tradeoffs of the aging, legacy items that suffer.
Don't get me wrong, a rewrite for rewrites sake is foolhardy, but Netscape 4.x is widely acknowledged to be one of - if not the worst browser on the planet. Regardless of the bloat, Mozilla is still a standards-compliant browser, and I'd be curious if the original author has tried Firebird. I am a Web designer, so a CSS/XHTML-based design is a bit more troublesome on the front-end. At the same time, it's far easier to change the entire layout of my site(s) and it's far easier to maintain accessibility with a CSS-based design.
At the same time, we've recently upgraded to Apache 2 and the performance improvements are far and away worth any amount of legacy support - IMHO. I admit I'm a bit biased as I'm not programming, I am seeing the fruits of the labor as an end-result. But if those fruits come at the cost of legacy support that appears to be "good enough" - that's not enough for me to justify....go ahead and rebuild...
Just my $.02
- bliSS
the only difference between a rut and a grave, are the dimensions
The problem is not whether they are good enough now, it's whether they will be good enough in the future. You can't predict what the future will bring, so if you rewrite your software to make it easier to include new stuff, then it's all good.
Also, it's unfair of him to compare HTML to an entire list of technologies. HTML is to XHTML, CSS1 is to CSS2, CSS3, etc.
XHTML 2.0 is going to be a bit of a massive move, but people can still choose to stick with XHTML 1.1. If anything I would say the changes are for the better.
Karma: It's all a bunch of tree-huggin' hippy crap!
Even thought the author of this artical complains about mozilla look how gnome got around XUL but just using the gecko piece of the code.
The author makes a few valid points. BUT... the author seems to be impling that the tech community should freeze.
I couldn't imagine all OS's being based on DOS, because "it's already there". Even the NT Kernel has many improvements. Linux as well. It's reinventing the wheel, but it's a better wheel.
XUL has the benefit of being truly cross platform, and standards compliant. It's easy to write/adapt. I don't know of any other standard that is.
Apache 2 is clearly the better Apache version. I don't think many debate that. What they debate is the failure to complete the job of getting the modules updated to utalize it. I don't know of many Apache users who aren't itching to get ahold of it for production use. As soon as all those modules are working 100%, there are many gains.
Funny the article didn't mention WinAmp 3... the one true case of bad rewrite.
Perhaps it is reinventing the wheel... Then again, you can go with your wooden carrage wheels, while I have a shiny crome rim with all terain tires... see who has a better time getting cross country.
reinventing can be a great thing. What's important is to do it in a way that smoothly transitions.
What's also important, is for people to realize that their technology, when connected over the net, must eventually be upgraded to keep up with the net. Slashdot is slow with a 14.4 modem. I know that. But is Slashdot at fault for that? Or is it unreasonable to expect slashdot to freeze development because someone won't upgrade their modem?
I sent this reply to the author through the site, but it would probably get some use here too.
"The Web was based on the idea that a simple markup language could allow us to divorce document presentation from document structure"
Which HTML 1.0 through 3.2 didn't really achieve, admittedly...
"Some of the changes to HTML were done in a way that shouldn't break old browsers, but as I said before, I am increasingly seeing websites that don't render properly in Netscape 4.x"
There's a shock. I thought it was 2004, and you're still testing on a browser which is at least three major revisions old, never mind that Mozilla itself seems to be more useful than Netscape's rebadged browser.
"So apparently the FONT tag is deprecated - now we have to use style sheets and whatnot to do something that was originally very simple"
This is because "the web was based on the idea that a simple markup language could allow us to divorce document presentation from document structure", and the FONT tag is presentation appearing in the document structure. That's sort of like a divorce where the couple still sleep with each other.
"but at the expense of being able to do simple things quickly."
I beg to differ. Even if I really want to break style guidelines and make a chunk of text red for no particular purpose, it still takes the same amount of time to type <span class="red"> than it was to type <font color="red">. Never mind that this really is a bad thing to do. Why is it red? Is there a meaning to the red? Perhaps it should be <span class="important">, in which case why not just use <strong>?
"As a Web developer I have long wondered why they didn't add more types to the INPUT form tags to express different types - for example, a DATE attribute, or INTEGER, DOUBLE, or whatever."
Of course XHTML 2.0 will be partnered with XForms, which will attain this functionality in so as far as any field which can store a value can be of an XML Schema type. This includes -- wait for it -- dates, integers, doubles, and arbitrary regular expressions.
"These "rich" (but simple! not XML!) attributes could then be seen by the browser and presented to the user in whatever way is supported by the system"
Hopefully they do this. I would love to see browsers implement a calendar popup. I can't count the number of times we had to use a JavaScript for this.
"But the direction we're going in, the HTML books have just become thicker and thicker over the last few years."
This I don't get. There are less tags now, right? It's the CSS and XSL books which should be getting thicker. By the way, never buy a book on XSL:FO. I accidentally dropped that on my foot, and christ, they hurt.
I think the progression from HTML 4.0 through XHTML 1.0 to XHTML 1.1 was smooth. They're encouraging people to go back to the roots of the web: to mark up content depending on what it means, not depending on how it's supposed to look. Sites like www.csszengarden.com are living proof of how the separation of HTML and CSS can achieve excellent separation of concerns between the graphic designer and the web developer, and I'd personally love to see more sites such as this (only with real content!) pop up all over the place. If for no other reason than the pages loading faster due to many, many less tags in the HTML! :-)
Karma: It's all a bunch of tree-huggin' hippy crap!
Fred Brooks described Second-System effect in his 1974 classic book, The Mythical Man-Month. I don't think there's a need to rewrite this book yet.
This just looks like a debate about power & extensibility vs ease of use (from a programmer's and sometimes user's point of view).
Basically, you can choose between a small and easy program that will do just what you need but is not designed to do anything else, and a very big and complex framework that will allow you to do whatever you want, but at the cost of making even small things very complex, because they will depend on the whole framework. Having a nuclear power plant behind you just to make a "Hello World" program is perfectly pointless.
This is also true from an UI point of view. When a new version of a special piece of software is released, I sometimes feel that I preferred the old one. The programmers wrote a Very General And Complete Thing which can do Anything They Want, but lost simplicity, both within the code and within the UI, since the user can now do zillions of things.
The result is that I often feel the new version should most of the time have a new name instead of software 2.0. Sure, it keeps quite a few things in common with the earlier version, but after a while, it will become so much more complex than what it was in the beginning, that I'll stick to the earlier version, or switch to another competitor.
I am assuming that you are using "Detailed Design Document" to mean a report written before programming commences that includes everything from the overall architecture all the way to what each function does. It is usually obsolete as soon as a programmer realizes that half the functions are unneeded because of the implementation. I find it quicker to write the program than to write that level of specifications, and I use platforms that have methods for discovering the details from the code IF THE CODE IS DOCUMENTED PROPERLY.
---
With LotusNotes, you name the design elements by their purpose. Almost everything is obvious, so if you want to check how a Field on a Form works, you look at the Form. Most of the code will included in the Field; everything else should be in the events code. Occasionally developers will hide code that affects one Field in a different Field; the "Design Synopsis" creates a quick searchable report to solve these issues. If anything is tricky, I add (hidden from users) design notes at the top of the Form where they are obvious to the maintainers. I do add a "DESIGN" page to define the workflow and architecture whenever it is not obvious.
I once was sent in to troubleshoot a very large project that was about to become overdue. The developers had their list of bugs. After about 10 minutes to familiarize myself with the architecture, they started describing the bugs one at a time. I was able to find the code that contained each bug in moments, and usually had it fixed in minutes. Then they would test the function with several versions of the clients (mostly MSIE, but also Notes clients) while I worked on the next bug. We fixed about 150 bugs the first day, and another 50 (including a few that required more than a simple code fix) the second day. This was possible because where the fix was needed was obvious because of where it appeared, and Notes makes it easy to find the code.
---
With Java, I include a text file that outlines the purpose and major architecture. I update that if there are any major structural changes. I also add comments for all classes and functions so that JavaDoc can create the specifications from the code. Bugs can be harder to track because the logic may pass through several classes (and of course each class is in its own file.) I have spent hours testing one class before realizing the bug is in a different class.
---
With C, the documentation is much more important because even the best design will get messy during implementation. I have not used any tools that compare to JavaDoc. I avoid using C for major projects, and have been mostly successful since Notes plus some Java is usually obviously the best solution for business apps. (C++ is closer to Java, but none of my clients are using it.)
---
I understand that when you have tons of developers working on a project, better documentation is necessary. But if you have tons of developers working on a project, the project will probably fail anyway (unless you hire a Linus clone to manage it.)
I spend my life entertaining my brain.
This is why Object-Oriented Programming is so important. When you think of your program in terms of a series of independent objects that are orchestrated to perform a task, you don't need to discard code that isn't being changed.
In my experience, I have seen very few projects that truly use OOP to its maximum power. Just the other day, I was leafing through the GAIM source, and let me tell you, it wasn't pretty. I personally haven't spent any time studying the code mentioned in the articles, but I'd be willing to bet that most failed rewrites come from code that is not modular.
If you start writing your program with any idea in your head, it might work out, and it might not...the only way to be really sure that your work is going to be of some benefit down the line is to assume that whatever you're writing will need to be replaced, and make that process as painless as possible.
IMO, portability, reusability, and time-effective maintenence are all dependent on OOP.
But there is another kind of evil that we must fear most... and that is the indifference of good men.
The problem of rewrites does absolutely not lie in the current codebase, but in what has happened before that. There are a couple of reasons why rewrites become necessary:
1. The system was not well specified or designed in the first place (eg. no modularization, no frameworks or reusability, no clear documents for the specification or design, client changes mind during development process)
2. Updates on the software were made ad-hoc on the code base and not to the specification, leading to out of sync specs vs. code base.
3. Pieces of code were used for things they shouldn't be used for (eg. using wrong types)
4. (very important) Changes in technology or changes in demand (eg. nowadays communication mostly goes with RPC using XML, whereas in earlier times each communication channel would use another structure and syntax. Another example: users are more demanding to receive mail spamfiltering with specialized bayasian filtering rules instead of simple keyword rules)
Ok, how to solve these very difficult problems (they are indeed difficult)?
First of all, design your system for change in mind from step 1. Build a prototype which has the capability to be extended and throw it away, so you can see how extendability can best be implemented on your specific project.
Second of all, use specifications and design documents, if necessary use UML diagrams so you can still understand the design after 4 years.
Third of all, design and build every part of your system as if you expect it to be reused, even if it is not going to be reused in your current application. Design with modularization in mind. Make sure that the design you made and the piece of code you wrote is only going to be used for what it is intended for (but use generalisation to give it a broad intended range of uses).
Fourth and most important, try to explain to your manager or client that in the long term quick hacks are going to cost alot more than work than solving the problem the right way.
This advice may be a bit oriented toward businesses instead of open source development, but opensource has one big pre: not as much time pressure.
This is a replacement signature.
First, IPv4 vs IPv6. Not only there is no pressing need to move to IPv6, most of the applications/tools/utilities are not written to accomodate IPv6. As simple as that.
Second, Perl. Personally, I gave up on this language, that is, won't be using it for any projects. First, there was a painful transition from v4 to v5, and now the happy Perl crowd want to present us with another painful transition, from v5 to v6. Thanks but no thanks. For all I care, Larry Wall and Co. are just the bunch of happy idiots who want to have fun but have no clue what production environment is all about. Perl is no longer a serious effort. it is a 'Church of Perl', with its true believers, and I'm having none of that. To be more specific, they don't talk about things like 'compatibility' or 'ease of maintenance'. Instead they talk about 'Perl as a part of post-modern culture'. enough said. They can have all post-modern culture they can eat.
1 is not only a Cisco problem; until they take the trouble and fix their boxen, there is a "coincidential" friction in IPv6 standardization which also just may have contributed to the fact IPv6 is not quite yet out there.
As of the argument in the original article that rewriting IPv4 into IPv6 is not a very good idea, anyone who has minded larger chunks of code should know that sometimes the old way simply is beyond repair. In this case, fixing NAT problems and re-enabling application- and vendor-independent end-to-end to the Internet simply requires a re-write. Hence, IPv4 vs IPv6 is not a very good example.
I wish Newtek was guilty of this. Instead, the current version of Lightwave 3D (6.x/7.x) is starting to fall apart under the load as the ancient Amiga codebase is pushed far beyond its original purpose.
While I hardly ever ran into bugs in their 5.x releases (and the ones I did find were minor), a significant slice of man-hours working in 6.x/7.x involve compensating for bug-related loss of functionality with workarounds, recovering from crashes etc.
They should have rewritten after releasing 6, but they didn't, and they probably won't survive the results.
That most grand projects "rewrite X from scratch" never reach the 1.0 level, or that they cost years beyond the original estimate?
One could do a lot of small bugfixing in that time
We can do even better in software (and other human tasks) than evolution, because we can make larger jumps and have an idea where we want to go and how to get there. It's the difference between getting a roadmap and driving from Lawrence, KS to Denver, and starting in Lawrence, closing your eyes, walking for a hour, and measuring your altitude. However, the risk is still the same - without a good idea where you are going, you can end up worse than you were. Think how social engineers thought communism and fascism were good ideas for societies, "if people would just implement it correctly". Thank goodness we have software models that let up abandon bad projects.
I'd agree that rewriting from scratch is bad - if you have to jump to the re-write right away. But we all know the rule of 3, at least for Microsoft - don't jump on until the third release. DOS 3.0, DOS 3.3, Windows 3.1, NT 4.0 Service Pack 3.0, Internet Explorer 3.0, etc. etc. It's the same with the other technologies - wait at you local maxima until the new maxima is proven to be significantly better.
However, "We're doing pretty good here" is a lousy reason to stay at a local maxima. Cochroaches are pretty successful biologically and evolutionarily, but I like the features we gave up to get to Human status.
Long story short, I and another fellow re-wrote the thing from scratch using PHP and MySQL. The whole rewrite took less time then it would take to debug a small change to the Excel app, and the distribution problems are gone... Success!
The author uses some examples where the original implementation is not necessarily as bone-headed as using Excel, but he still misses the point that sometimes a rewrite is just WORTH all the pain.
W..w..W - Willy Waterloo washes Warren Wiggins who is washing Waldo Woo.
Anyone who has worked on major projects where features are added over time periodically realize that rewriting sections or even completely starting over on the project usually leads to better implementations including the fixes and tweaks.
Openbox really surprised me by being a great program even though it was a rewrite.
About half of the rewrites I've seen have ended up as a better program than what went before, and half of them went nowhere and the program died. Sometimes it's OK to stop and say "this program is going nowhere. A rewrite is necessary".
Other examples are Rosegarden, for example, and hasn't Perl been rewritten successfully in the past? (We'll see what happens to Perl 6.)
From:- Enginee ring-and-Computer-Science/6-170Laboratory-in-Softw are-EngineeringFall2001/BD7247F9-DD02-42D2-B8E9-75 FF01E4F868/0/lecture01.pdf
... Were paying the price for going fast.
http://ocw.mit.edu/NR/rdonlyres/Electrical
Netscape Story
For PC software, there's a myth that design is unimportant because time-to-market is
all that matters. Netscape's demise is a story worth pondering in this respect.
The original NCSA Mosaic team at the University of Illinois built the first widely used
browser, but they did a quick and dirty job. They founded Netscape, and between April
and December 1994 built Navigator 1.0. It ran on 3 platforms, and soon became the
dominant browser on Windows, Unix and Mac. Microsoft began developing Internet
Explorer 1.0 in October 1994, and shipped it with Windows 95 in August 1995.
In Netscape's rapid growth period, from 1995 to 1997, the developers worked hard to
ship new products with new features, and gave little time to design. Most companies
in the shrink-wrap software business (still) believe that design can be postponed: that
once you have market share and a compelling feature set, you can refactor the code and
obtain the benefits of clean design. Netscape was no exception, and its engineers were
probably more talented than many.
Meanwhile, Microsoft had realized the need to build on solid designs. It built NT from
scratch, and restructured the Office suite to use shared components. It did hurry to
market with IE to catch up with Netscape, but then it took time to restructure IE 3.0.
This restructuring of IE is now seen within Microsoft as the key decision that helped
them close the gap with Netscape.
Netscape's development just grew and grew. By Communicator 4.0, there were 120 developers
(from 10 initially) and 3 million lines of code (up a factor of 30). Michael Toy,
release manager, said:
We were in a really bad situation... We should have stopped shipping this code a year ago...
It's dead... This is is like the rude awakening
Interestingly, the argument for modular design within Netscape in 1997 came from a
desire to go back to developing in small teams. Without clean and simple interfaces, it's
impossible to divide up the work into parts that are independent of one another.
Netscape set aside 2 months to re-architect the browser, but it wasn't long enough. So
they decided to start again from scratch, with Communicator 6.0. But 6.0 was never
completed, and its developers were reassigned to 4.0. The 5.0 version, Mozilla, was
made available as open source, but that didn't help: nobody wanted to work on spaghetti
code.
In the end, Microsoft won the browser war, and AOL acquired Netscape. Of course
this is not the entire story of how Microsoft's browser came to dominate Netscape's.
Microsoft's business practices didn't help Netscape. And platform independence was a
big issue right from the start; Navigator ran on Windows, Mac and Unix from version
1.0, and Netscape worked hard to maintain as much platform independence in their
code as possible. They even planned to go to a pure Java version ('Javagator'), and built a
lot of their own Java tools (because Sun's tools weren't ready). But in 1998 they gave up.
Still, Communicator 4.0 contains about 1.2 million lines of Java.
I've excerpted this section from an excellent book about Netscape and its business and
technical strategies. You can read the whole story there:
Michael A. Cusumano and David B. Yoffie. Competing on Internet Time: Lessons from
Netscape and its Battle with Microsoft, Free Press, 1998. See especially Chapter 4,
Design Strategy.
Note, by the way, that it took Netscape more than 2 years to discover the importance of
design.
Guilty until proven innocent aka the American way.
...a big ball of mud. The thing that you really don't want to throw out and redo from scratch is the documentation that ought to accompany a project - if the behaviour of the code is fully documented, then a you can decide what if any functionality you throw away when rewriting the code.
Background: I work on a very large, critical finance system. Literally millions of dollars can be lost when out stuff does not work. This is my first job after college, all prior projects I've worked on were smaller (I usually lead them).
Anyway, when I was in school, one of the little concepts I picked up and became enamored with is the idea of a throw away prototype. The idea is simple: plan to throw away your first implementation. That way, you implement it, learn the shortcomings of your design, and make a new design which now encorporates your new experience with this.
The idea is really one that needs to be accepted: you're going to make mistakes during your design. If you plan to throw away your first prototype, it drives you to accept and correct your errors rather than kludging and hacking your original design.
This is fairly accepted and fairly standard practice.
Now, my opinion (based on experience)... When you've been working on a project long enough, you start to feel what the design did and did not anticipate, even if you no longer even know who did the design. You start to know what kinds of changes are easy to make, what kinda changes are hard. You also learn what kind of changes are most often needed, and the ones you have to hack around the most.
I think you know where I am going with this...
At some point, you start learning the same types of lessons from working on your code that you're supposed to learn from your throw-away prototype. At some point you start to keenly feel where the shortcomings are.
So logically, if you understand how to improve your program through a rewrite, you should do it. But only once you really understand the old code enough to learn how to genuinely improve it for the practical considerations.
This is where object oriented or at least modular, design pays off. If you can do a rewrite (or redesign) of your whole program without really having to rewrite some chunks (that you know are good), you're really ahead.
Ecce Europa - Web Design for Business
Well, that's exactly why old software has to get rewritten. The guys who wrote it have moved on to other pastures. Great, the code works semi-brilliantly, but you cannot find another person on this green earth who can figure out why. Which means it cannot be maintained. It's an intensly complicated finely tuned morasse of code that nobody can modify.
So at that point you either concede defeat and abandon the product, or hope you have enough inertia in the market that you can rebuild something based on it.
Hire people on to meditate on the code enough to grok it and extend it, you say? That'll take just as long if not longer, and you'll be at the mercy of a couple of primadonna asshole programmers who know they have your company by the balls. Not an option.
Been there, done that.
Maybe this has already been mentioned, but why dont you just encapsulate the environments.
If an application works using Perl 5, then dont migrate it to Perl 6!! Encapsulate it and access it as a seperate process or web service.
An application works with Apache 1.x, but you want to start using Apache 2.x. Well, run Apache 1.x on one machine, and 2.x on another and access the 1.x app through web services.
Companies still run code from the 1960s on mainframes. They're not "forced" to upgrade. There is still a demand for COBOL programmers.
Maybe I didn't RTFA well enough, but if Neil Gunton did more homework, he would find that we have been using the solution all along.
+1 Humble
Joel on Software has an excelent article which is worth a read and is exactly on this topic(but written a couple years ago)...
you go on and continue using netscape 4.x then...
tcp/ip sometimes does not work at all ... all internet uses are used to the fact that sometimes they have to restart their download or hit F5 to reload the page, etc ... .. it only means that it is 'better then nothing'
... yes of course, fancy stuff like NAT can route the packets, but takes the interconnectivity out - you can't connecto from everywhere to everywhere anymore ...
......
yeah
but it does not mean that it is 'good enough'
as for the address range
yout local NAT is your god
apache - have you ever tried to write an application using more then one thread ? do you know what it is all about ? to get all the threads working together rather then slowing down each other ? probably not, otherwise you would not say something like: 'Couldn't we have instead built on the existing code, which by now is extremely robust (if a little messy)...'
perl - who suggest you to use perl 6 ? noone
so how you can be so cheeky and try to suggest to all those people having their fun with that development that they should do something 'more useful in your eyes' and continue development on perl 5 ?
'Browsing the Web is browsing the web, and it's pretty much the same for me now as it was back in 1998.' -> don't be so selfish and put the question differently:
is the browsing the web for WEB BROWSER the same things as in 1998 ? NOT ! now it has to handle all the fancy stuff which wasn't being really used THAT time
case 7 -> windows xp is only extension/bugfix/upgrade of windows 2000
if you want to talk about windows and rewrites - WHY they have written windows NT ? why couldn't they build SERVER operating system based on WINDOWS 3.11 or WIN95 ????
There is sort of a benefit to having output plugins...
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
Yeah, pretty much. But I'm in the military, so I'm definitely used to that. :)
!#@%*)anks for hanging up the phone, dear.
Maybe we need rewrites is because our code is so brittle. Brittle in spec, brittle in design, brittle in implimentation. Present day code is designed with the same thinking that gave us bottom-dollar hardware, and the attendent problems. Just what's needed (and sometimes not even that) and no more. Our hardware use to last long times, and some of our code have that same quality. But few. More intelligent design, and careful thinking would go a long way to reducing the amount of rewriting needed.
However, if you're talking about a larger project such as a commercial software application with 50 man-years of development, a complete rewrite will usually be undertaken with a large degree of ignorance of the true problem domain. Also, you can rewrite your codebase to fit more nicely with the *current* state of your specs and requirements, but the new "elegent" design may be even less suitable to tomorrow's new feature request. Even rewriting a major subsystem from scratch can be a costly mistake.
The real trick is how to maintain the code in such a way that it continuously improves instead of just getting more and more riddled with spaghetti, dead code paths, and other clutter. It's especially hard, because it's easy to forget to treat a mature code base with respect, and just hack in "one more" thing because you are hoping to rewrite it at some point.
There is the "broken window" idea--one broken window will lead to an increasing spiral of vandalism, and one line of crud in a source file will give future programmers the feeling that they can add ten more lines of crud because the code is already "dirty". While the usual adage is to clean up the window immediately, the reality is that most source files have one hundred broken windows already and fixing them all right now is not an option. What takes discipline is to make sure to leave each file in a better condition than you left it--remove some dead code, do a little refactoring to clean it up, rename identifiers or reformat code to conform with project-wide standards (NOT your personal pet style!!! This is very annoying when people check out a file, reformat it to their own preference, add one small feature, break some other part of the code, and check it back in to source control...). Another common problem is when people come up with some "new religion", convert about half the code over to the new way, but leaving it in a "worst of both worlds" state because it turns out the "new way" was just "different" and added as many problems as it solved. It is easy to add code that goes against the grain of the existing code because you didn't bother to really understand the system and structure of the code, or because you don't "like" a certain design decision.
In many ways, the real achievement is that higher mental state where you stare at the huge, messy codebase that you've been working with for ages, have the "aha" moment, come up with a simple refactoring, make changes to fifty files, replace hundreds of lines of code with tens of lines, and it just works the first time and only takes a few hours, because for one fleeting instant, you had the whole thing in your head at once. I wish I could have more of those moments.
I'm as guilty as any for violating these ideas--I often keep my nice clean "new" subsystems tidy because they are already tidy and conform to my current design philosophies/religion, but let my big, mature--and often more imporant--subsystems grow increasingly crudified because I have the continuing fantasy that I will be rewriting them from scratch "next project"...
Yeah, so Brooks tells us "prepare to throw one away", that your first system is a prototype that gets scrapped when you do the real system. But then he says people get cocky that they know how to live life over and not make the same mistakes the second time around, and second systems are overwrought. Dunno.
Ain't that the truth. This advice also applies to slap-dash work, too. You know the kind:
Hacks are inevitable. The least one can do is take a minute to include a little note explaining just what you were thinking. Also, deleting the existing comment which no longer applies would be nice.
There have been times when my hacks have been so frightful, so horridly brittle, that my explanatory comments conclude with an apology to whichever poor sap gets the responsibility of maintaining it.
I think some assinine admins would respond to your VoIP and desktop as web server arguments as being ignorant. Remember the BOFHs have little interest in YOU admining your own box. It's much better for them if they restrict what you can do because then they have fewer liabilties. Largely this is because they are a lazy lot.
Do what you got to do in a limited time frame.
If you have the time, maybe a rewrite is appropriate. You would do this for things like the Mars Rover, But for Time-To-Market and budget concerns, you often have to release what you have.
Later on, as time permits, you release patches and fixes, or make recalls.
Heck, it will never be "Perfect". There will always be something wrong. That's where you get into version numbers and law suits. If it works good for a while, it is a success. If it fails, blame somebody else.
Regards,
I worked as a programmer myself & I was constantly amazed at how majority of code hackers will waste enormous amounts of time writing code to solve a problem that has already been solved.
This is one of the pifalls of development facing a vigilant manager.
Q.E.D.
When I am king, you will be first against the wall.
HTML was not intended to describe the look of a page. So what? It was used for that and it did the job pretty well. There are many things in the world that are used in other ways as the original design.
The basic function of stylesheets is the same as what you are using constants for in a program: replacing duplicates with a central copy. But in programming no one would use constants if there is no problem with duplicates.
Compare this with the font problem. There is no reason why <font> and <style font=> couldn't be synonymes. It would make the browser simpler, it would provide backward compatibility, it would make (X)html files simpler and shorter. One could go on: there is no reason why the syntax of a stylesheet is so different from HTML.
XHTML/CSS is for me a very complicated way to solve a very simple problem.
This is the "second version" effect that is described in the classical book The Mythical Man-Month by Fred Brooks.
Using Set from the cmd line will only change the environment value for the duration of the cmd line session and will not propagate to the entire operating system as a whole. It is only good for that session and within that session.
Also, the ctrl+break combination is incorrect. It's the Windows key + Break.
Lastly, environment variables shouldn't be changed all that often. So, from a user interface view, they don't need to be readily accessible. If you know of a case where they do need to be changed frequently on a system level, I would be interested to know about it.
Ryosen
One man's "Troll, +1" is another man's "Insightful, +1".
However, they are nowhere near the level of usability and simplicity found in Galeon for the following reasons:
- They are not part of a stock installation, and therefore require a fairly hardcore geek to even know about them (I consider myself a very hardcore geek, and I was not even aware of these extensions). Therefore, to a "normal" non-technical user, these extensions do not exist.
- To close a tab you have to pull down a menu and select close. Contrast this with a small X right on the tab in Galeon. One click, goodbye. No pulldowns. No problems.
- Too many features - "close all tabs to the right of this one", "close all other tabs", etc. Too many "noise" choices cluttering up the overwhelmingly common use case.
Don't get me wrong. I come not to "dis" Tabbrowser Extensions, only to point out how Galeon really gets the common use case right. That said, I do intend to check these extensions out. Might make Mozilla tabs more bearable.Hey, Windows users, there is no such thing as "forward" slash, there is only slash and backslash.
Say what? It's not like there haven't been hundreds of new features added in to ipv4 (e.g. slow start, SACK, window scaling, timestamps, ECN, etc. etc.) before they had to just bite the bullet and make a non-backward-compatible change. Once you're making one, you should make all the ones you'll need for a long time in the future, which is what ipv6 does (assuming they didn't miss anything...).
BTW, a good analogy for the address space problem is street numbers for houses. Sure there are lots of unused numbers, but most of them are between two existing buildings where there isn't room to put new buildings. (IP addresses have this problem because routing works based on nets and subnets, so routers don't have to know a separate route for every different host.)
#define X(x,y) x##y
Peter Cordes ; e-mail: X(peter@cordes ,
"Definition & Example of Refactoring"
Refactoring?
In his book, Martin Fowler defines Refactoring as "the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure." In other words, you clean up your code but don't change what it does.
Refactoring can be as simple as changing this code:
$exclamation = 'I like '.$pastry.'!';
To this:
$exclamation = "I like $pastry!";
Still does the same thing, but it's easier to read.
It's important to note that I don't need to know anything about the contents of $pastry or how $exclamation is used. The change is completely self-contained and does not affect surrounding code or change what it does. This is Refactoring.
That a reheat of the old evolutionist vs revolutionist issues : see http://incubator.apache.org/learn/rules-for-revolu tionaries.html
All those example would have been great if they have follow the proper rules for revolution instead of declaring them the next version.