I think it was just a funny figure of speach, rather than a fact... It is a great wtf indeed, but luckily netscape doesn't control a heart rate monitor or anything... A friend of mine is a testing engineer at a company that produces software for hospital equipment, she's dealing the sort of software that really really really has to work, come hell or high water. I'm talking robust with capital R... So far no casualties... :)

Anyhow, thanks for this WTF. I didn't realize how much AOL's influence affected Netscape's development and functionality after the acquisition...I'd wondered if AOL would do something like that but didn't follow the details too closely, and sure enough.

I think the main WTF here is AOL's idiocy and its let's-listen-to-marketing-above-all policy more than Netscape itself. It's a shame AOL is essentially no more, though, we're missing out on the possibility of many more AOL-related WTFs in the future..

Ack, I remember Netscape 7, and remembering that the only feature N7 vs. Mozilla 1.0 had was that Netscape 7 had an AOL Instant Messenger client built into it, while Mozilla didn't (it had Chatzilla). I also remember the WTF of Netscape 6 - I was a beta tester for it :-/

A strictly-conforming C program may convert an object pointer (though not a function pointer) to a string by casting it to void* and formatting it using sprintf with the %p format specifier (provided the receiving buffer is large enough for the output). Such a string may be stored in any suitable medium and later converted back to an object pointer of the original type (via sscanf) and used, provided it's used during the lifetime of the object that it points to, without invoking undefined behavior.

It's spelled out in black and white in ISO 9899-1999:TC2. The real WTF is that some people still haven't memorized every single word of the C specification. Geez.

(Prolepsis: Of course I agree pointer->string->pointer is not a Good Idea.)

Most of the features users want are not promised to them at all by the people that know better (i.e. the manager with a masters degree and no coding experience vs. the programmer with 10+ years of code slogging and a college dropout with a "C" average). The ones they hate are usually "undocumented features".

A strictly-conforming C program may convert an object pointer (though not a function pointer) to a string by casting it to void* and formatting it using sprintf with the %p format specifier (provided the receiving buffer is large enough for the output). Such a string may be stored in any suitable medium and later converted back to an object pointer of the original type (via sscanf) and used, provided it's used during the lifetime of the object that it points to, without invoking undefined behavior.

It's spelled out in black and white in ISO 9899-1999:TC2.

Yes, but does the spec say anything about what should happen if that string is passed through a Javascript applet? I'm fairly sure that's undefined behavior.

Speaking of marketing department-induced WTFs, are any other loyal Opera users really turned off by the Opera 9 propaganda (currently visible in the Sponsored By widget on this site)? Those "example" users are so stereotyped, none of them are actually like you at all, no matter who you are. If you follow the link and read the copy, it comes off like the campaign was designed by a high school student.

(Edit: Okay, so I clicked this ad, and I was lead to a user-friendly feature list instead of the crappy marketing stories. Maybe they ditched everything but the silly photos of supposed Opera users.)

Speaking of marketing department-induced WTFs, are any other loyal Opera users really turned off by the Opera 9 propaganda (currently visible in the Sponsored By widget on this site)? Those "example" users are so stereotyped, none of them are actually like you at all, no matter who you are. If you follow the link and read the copy, it comes off like the campaign was designed by a high school student.

(Edit: Okay, so I clicked this ad, and I was lead to a user-friendly feature list instead of the crappy marketing stories. Maybe they ditched everything but the silly photos of supposed Opera users.)

Ther is an opera ad? Where? All I see is the two BG girls. Why oh why can't we get BG Girls, beanbag girl and foosball girl all in one ad? I'd never log out!

As for todays WTF, isn't this how all companies release a product these days? Gone are the days where people actually took pride in the software they released to the public. Oh wait, those days never really happened did they. All good software releases were accidents corrected in the next version.

Oh Blake, this WTF was awesome, but I wish you'd used the opportunity to share some dirt about how the hell Mork happened. (Unless it's just "The guy didn't have a clue what he was doing," but, well, it's *got* to be funnier than that! Look at it!)

Speaking of marketing department-induced WTFs, are any other loyal Opera users really turned off by the Opera 9 propaganda (currently visible in the Sponsored By widget on this site)? Those "example" users are so stereotyped, none of them are actually like you at all, no matter who you are.

They seem a like a little weird choice for spokespeople, but I don't let things like that bother me. It's just advertising. Everything in advertising is fake.

The story with Netscape 6 is not so straight. Remember, by that time Netscape and all the Mozilla volunteers had worked for years, Netscape marketshare was going down, and there was basically nothing to show. So Netscape 6 was released in a hurry to put something at least barely usable out. It was known to be pretty horrible, but the marketing was well done and the press loved it. Until they tried to use it for a couple of days...

So yeah, it turned out to be even crappier than expected, and the backslash was pretty bad marketing.

But what most people fail to realize was that it was great for engineering. The web was full of articles how Netscape 6 failed in this or that. It was tracked pretty carefully by Netscape and the community QA, and bugs were filed. Netscape 6 included also the crash reporting tool (Talkback), and it sent tons of crash data back to Netscape. In about 6 months Netscape 6.1 was released, and it was an amazing leap from 6, mostly because of the enormous feedback from Netscape 6. And it just got better and better from there (barring marketing mishaps like 7 without popup blocking).

The first 20 million copies of Netscape 7.1 (I think, been a while), was downloaded in a lot shorter period than Firefox 1.0's 20 million, and there was no marketing push for 7.1 at all. So although 6 was a marketing disaster, by 7.1 there were a lot of people happy with the product and downloading it without any marketing effort.

Throwing away the release 4 code is one - that was working and
tested code, even if full of bloat. See http://joelonsoftware.com/ -
the guy explains it much better.

I knew someone was going to bring up Joel's "never throw away the code" article.

Joel is dead wrong and so are you. In fact I recommend reading The Big Ball of Mud,
as it's far more insightful and sheds light on the unfortunate and
seemingly inevitable cycle of code becoming so bloated and tangled that
it has to be thrown away, because it reaches a point where over 99% of
developers' time is spent on maintenance or just plain scratching their
heads. (I firmly believe it is possible to *not* end up having
throw away a codebase, even after decades, but it requires much more
diligence and skill than most programmers are willing to exercise, and
it requires a manager with a clue where software development is
concerned.)

I'm especially surprised that anyone still stands
behind Joel's article, considering the success of Mozilla and the fact
that it's brought an excellent browser to so many platforms.
Looking back, throwing away the Netscape 4.x code seems like the best
thing that's ever happened to the browser world.

Well, I doubt Mozilla proves anything either way. First, the Mozilla development was a death-march of feature creep and over-engineering. Who knows if it might have been a lot faster if they just fixed the old base? And Firefox is the real success story, not Mozilla, and its developers didn't throw away the Mozilla codebase, as ugly as it is (I love running into bugs in the Mozilla API, checking the code, and finding an unimplemented stub function).

Throwing away the release 4 code is one - that was working and tested code, even if full of bloat.

You must be using a different meaning of 'working' to the one I am used to. Its CSS support in particular was unbelievably bug-ridden, and I understand the code was such a tangled mess that there was really no chance of CSS ever being made to work.

I actually liked Netscape 4, 6 and 7. Reason? I made a good living writing all of my CSS, HTML and Javascript code two and sometimes 3 times to get it to work right in IE, NS4.x and NS6+. Its unreal how many companies standardized on NS 4 and then 6. It made programming the web hell, and also very profitable at the same time. 3x the work == 3x the fees. :-)

Throwing away the release 4 code is one - that was working and
tested code, even if full of bloat. See http://joelonsoftware.com/ -
the guy explains it much better.

I knew someone was going to bring up Joel's "never throw away the code" article.

Joel is dead wrong and so are you. In fact I recommend reading The Big Ball of Mud,
as it's far more insightful and sheds light on the unfortunate and
seemingly inevitable cycle of code becoming so bloated and tangled that
it has to be thrown away, because it reaches a point where over 99% of
developers' time is spent on maintenance or just plain scratching their
heads.

I don't think you quite got the point of Joel's article. It wasn't that code never has to be rehashed, sometimes extensively. As you and Joel both know, it does. The point is that throwing everything out and starting from scratch is the wrong way to go about that, especially if you want to be commercially successful. The correct and commercially successful way to rehash your code is to do it a bit at a time, moving this here, moving that there, untangling this knot, sweeping all the lint away from that other ball of mud over there, and at each step your code still does exactly what it did before, and you can still ship it if you have to. But after a certain period of time, you have a code base that bears almost no resemblance to the old one, but contains exactly the same well-tested functionality, and if you are even a little bit careful, no new bugs. For Joel this process took two weeks. For Netscape 4.x I can imagine it might have taken a bit longer, but not 3 years!

Throwing away the release 4 code is one - that was working and tested code, even if full of bloat.

You must be using a different meaning of 'working' to the one I am used to. Its CSS support in particular was unbelievably bug-ridden, and I understand the code was such a tangled mess that there was really no chance of CSS ever being made to work.

Throwing away the release 4 code was a WTF for sure since it was what killed the Netscape browser. Maybe refactoring the code wouldn't have worked, but we now know that the total rewrite was a WTF!

A strictly-conforming C program may convert an object pointer (though not a function pointer) to a string by casting it to void* and formatting it using sprintf with the %p format specifier (provided the receiving buffer is large enough for the output). Such a string may be stored in any suitable medium and later converted back to an object pointer of the original type (via sscanf) and used, provided it's used during the lifetime of the object that it points to, without invoking undefined behavior.

It's spelled out in black and white in ISO 9899-1999:TC2. The real WTF is that some people still haven't memorized every single word of the C specification. Geez.

(Prolepsis: Of course I agree pointer->string->pointer is not a Good Idea.)

It may well be permitted by the standard, but it's potentially confusing to the programmers. (There's all sorts of standards-compliant but insane things that can be done with C, anyway - see the IOCCC for some examples.)

Throwing away the release 4 code is one - that was working and
tested code, even if full of bloat. See http://joelonsoftware.com/ -
the guy explains it much better.

I knew someone was going to bring up Joel's "never throw away the code" article.

Joel is dead wrong and so are you. In fact I recommend reading The Big Ball of Mud,
as it's far more insightful and sheds light on the unfortunate and
seemingly inevitable cycle of code becoming so bloated and tangled that
it has to be thrown away, because it reaches a point where over 99% of
developers' time is spent on maintenance or just plain scratching their
heads.

I don't think you quite got the point of Joel's article. It wasn't that code never has to be rehashed, sometimes extensively. As you and Joel both know, it does. The point is that throwing everything out and starting from scratch is the wrong way to go about that, especially if you want to be commercially successful. The correct and commercially successful way to rehash your code is to do it a bit at a time, moving this here, moving that there, untangling this knot, sweeping all the lint away from that other ball of mud over there, and at each step your code still does exactly what it did before, and you can still ship it if you have to. But after a certain period of time, you have a code base that bears almost no resemblance to the old one, but contains exactly the same well-tested functionality, and if you are even a little bit careful, no new bugs. For Joel this process took two weeks. For Netscape 4.x I can imagine it might have taken a bit longer, but not 3 years!

Nice theory. I'm currently working on a code library that, sooner or later, is going to need to be re-written from the ground up. It's a cross-platform compatibility library, designed around the limitations of Windows 3.1 and Macintosh System 6. The memory allocation system is based around allocations of 64KB or less, the polling-based main event loop is incompatible with the MacOSX system of registering event callbacks, and the file-access sytem is based around the assumption of 8.3 filenames. There's leftover code from the days when this library supported things like VAX VMS, or a windowed application in a character-based display, and code for handling both ASCII and EBCDIC.

Further, the whole thing is written in object-oriented C, with all the fun that entails, and it's optimized for code size, not maintainability.

Yes, both of these are theories. Which one is more appropraite depends on the situation. I have encountered situations where cleaning up an existing code base was the right way to go and also times when trashing the current and starting over was right.

Regretfully I can't say I have always made the right decision the first time. With this in mind, you never delete your old code until your new fully written version is completed. You never know when you may need to fix a mission critical issue in the old code while it is still in production.

Throwing away the release 4 code is one - that was working and
tested code, even if full of bloat. See http://joelonsoftware.com/ -
the guy explains it much better.

I knew someone was going to bring up Joel's "never throw away the code" article.

Joel is dead wrong and so are you. In fact I recommend reading The Big Ball of Mud,
as it's far more insightful and sheds light on the unfortunate and
seemingly inevitable cycle of code becoming so bloated and tangled that
it has to be thrown away, because it reaches a point where over 99% of
developers' time is spent on maintenance or just plain scratching their
heads. (I firmly believe it is possible to *not* end up having
throw away a codebase, even after decades, but it requires much more
diligence and skill than most programmers are willing to exercise, and
it requires a manager with a clue where software development is
concerned.)

I'm especially surprised that anyone still stands
behind Joel's article, considering the success of Mozilla and the fact
that it's brought an excellent browser to so many platforms.
Looking back, throwing away the Netscape 4.x code seems like the best
thing that's ever happened to the browser world.

I don't feel myself clever enough to give general advice to everyone lkie "don't throw away your code" or "goto is evil" but I know one thing from my own experience. On numerous occasions I accidentally or deliberately threw away some pieces of code I had written and opted to rewrite it. The result, compared to the original one was always much better. I really don't know why, I suppose it was because I vaguely remembered the major pitfalls but forgot how I evaded them, but that's only a theory.

Yes, both of these are theories. Which one is more appropraite depends on the situation. I have encountered situations where cleaning up an existing code base was the right way to go and also times when trashing the current and starting over was right.

Regretfully I can't say I have always made the right decision the first time. With this in mind, you never delete your old code until your new fully written version is completed. You never know when you may need to fix a mission critical issue in the old code while it is still in production.

To throw out a horribly messed up project or to stick with it and try to mend it is perhaps the most complicated and delicate decision a manager has to make in this industry. That's why ithe wrong way is chosen so many times. Because if management has a clue, the project doesn't get messed up to the extent to force this decision.

Throwing away the release 4 code is one - that was working and
tested code, even if full of bloat. See http://joelonsoftware.com/ -
the guy explains it much better.

I knew someone was going to bring up Joel's "never throw away the code" article.

Joel is dead wrong and so are you. In fact I recommend reading The Big Ball of Mud,
as it's far more insightful and sheds light on the unfortunate and
seemingly inevitable cycle of code becoming so bloated and tangled that
it has to be thrown away, because it reaches a point where over 99% of
developers' time is spent on maintenance or just plain scratching their
heads. (I firmly believe it is possible to *not* end up having
throw away a codebase, even after decades, but it requires much more
diligence and skill than most programmers are willing to exercise, and
it requires a manager with a clue where software development is
concerned.)

I'm especially surprised that anyone still stands
behind Joel's article, considering the success of Mozilla and the fact
that it's brought an excellent browser to so many platforms.
Looking back, throwing away the Netscape 4.x code seems like the best
thing that's ever happened to the browser world.

This article should be taught at every university!

Just the other day I tried to explain to a coworker Conway's Law (without actually knowing that it was Conway's) in an argument about whether to tear down a layer in our product. It originally represented an organizational border but as the front lines have shifted since, now it's only an abandoned trench strewn with loose bits of barbed wire and land mines.

Just the other day I tried to explain to a coworker Conway's Law (without actually knowing that it was Conway's) in an argument about whether to tear down a layer in our product. It originally represented an organizational border but as the front lines have shifted since, now it's only an abandoned trench strewn with loose bits of barbed wire and land mines.

Do you mean the Big Ball of Mud article? It was taught at my university. I had to read that entire page and write a short paper about it. This was in my Software Engineering 1 class. *shrug*

As for putting a C class pointer into JAVASCRIPT..... Putting it into a string may be supported but a JAVASCRIPT string? I think I'm now dumber having heard that...