Slashdot Speaks (or Snarls, in Some Cases!)

and Joel Responds

 

In December of 2001 we published a two-part interview with Joel Spolsky, resident guru of www.JoelonSoftware.com and cofounder of Fog Creek Software (www.fogcreek.com), publisher of FogBUGZ and CityDesk, a desktop-based content management system (reviewed on this site).

 

Our interview was reported on at www.slashdot.org, a lively location on the web dedicated to expounding the joys of Open Source programming, Linux, UNIX, and anarchy (among other things). Visits to www.softwaremarketsolution.com shot to 40K page views in a single day and in turn generated a lively new thread on Slashdot about the ideas and viewpoints expressed in the interview.

 

To peruse the thread at your leisure, go to http://slashdot.org/articles/01/12/04/2034223.shtml. (We warn you in advance that the language and opinions expressed can become raw and rude but you will not be bored.) After browsing through the thread we extracted some of what we regarded as the most interesting comments and disagreements with Joel's ideas and concepts and asked him to comment.

 

Click on http://slashdot.org/articles/02/03/19/1321239.shtml?tid=156to read the new Slashdot thread dedicated to discussing this article.

 

SMS: Joel, in one of your earlier columns on www.JoelonSoftware.com, and in the interview, you stated that code doesn't rust, i.e., that once a piece of a program has been debugged and various workarounds added, it represents a repository of stored knowledge and should be left alone. However, many Slashdot'ers disagreed and one seems to quote a reputable source -- Stephen Eick, who wrote a paper for the IEEE "Called "Does Code Decay?" Our Slashdot'er quotes from the paper that:

 

"A unit of code is decayed if it is harder to change than it should be, measured in terms of effort, interval, and quality."

 

He goes on to say:

 

"The source of their data was the entire change history of a 15-year old real-time software system for telephone switches with over 100 million lines of code. What they did is measure the number of files that a single change had to modify. What Eick found was that once the initial development flurry of activity died off the probability of a change needing to result in modifying more than one file was less than 2%. Within five years the probability had increased to greater than 5%. It is Eick's contention that this is a sign of code decay because the number of "simple" changes was dropping and the number of complex, involved changes was increasing."

 

What do you think of this argument?

 

Joel: It may be true for the software that Eick evaluated. It's not true for the software that I've written, because I tend to refactor and clean things up regularly. Half the time when I go into a function to fix a little bug, I figure out a cleaner way to rewrite the whole function, so over time it gets better and better.

 

So for example whereas one change to the Filter feature would have required you to touch code in about 10 places in FogBUGZ 2.0, it requires you to touch code in one place in FogBUGZ 3.0, because at some point I spend some time rearranging all that code to make it more maintainable. I like refactoring (read my piece Rub a Dub Dub). But not everybody writes code well.

 

SMS: Your comments about it being a bad idea to ever rewrite code from the "ground up" generated a lot of comments, many of them negative, on Slashdot. Let me ask you: IS there ever a time when a complete ground up rewrite of a program IS justified? And let's confine ourselves to commercial software; I imagine if someone is creating programs for academic or research purposes, or perhaps as a hobby, the issue is not as germane.

 

One quote that sticks out from the Slashdot thread is:

 

"BUT JEEZ, should you hold on to a payroll system written in FORTRAN69 (or LISP or ALGOL or FORTH...), just because it works, even if you have NO OTHER apps in FORTRAN and don't have one single FORTRAN programmer working for you????"

 

This also stood out in our opinion and, as a former Microsoft employee, it may resonate with you:

 

"There are actually LOTS of reasons to do a ground up rewrite. I wasn't being sarcastic when I mentioned Outlook, nor was I bashing MS, I know and like a lot of them and respect many of their products. Many Softies are terminally embarrassed by Outlook and all the problems it has caused.

 

The architectural design of Outlook is so poor that it has led to billions of dollars of lost data and systems damage. Yet, because of all of the things that Joel has promoted (and MS' ego), they keep recreating that program, version after version. The mistakes of the earlier versions are retained and the new version has new exploits created as a consequence of the old architecture."

 

What do you think? What about that FORTRAN situation? And is Outlook a candidate for a ground up rewrite?

 

Joel: First of all, yes, you should hold onto a program in FORTRAN "just because it works." Don't even talk to me about spending money replacing something that works. The only question that is relevant is -- what does it cost to fix it if it doesn't work? For the sake of argument let's say that it costs you three times as much to add small new features to the old FORTRAN program because you have to hire retired consultants who charge extra to be dragged away from their golf games.

 

OK, so tell me the net present value of the stream of the marginal extra cost of those extra-expensive consultants for all future expected repairs. If that number exceeds the NPV of the rewrite, OK, fine, rewrite it, you have made an economic argument that it pays off. Not an emotional argument about old fashioned programming languages, which doesn't impress me -- an economic argument.

 

Now let's look at Outlook. There are hundreds of developer years tied up in that code base. 99% of the code is fine. 1% of the code isn't. Throwing out the whole code base and beginning from scratch is extremely unlikely to be cost-effective, because you have to reproduce most of those hundreds of developer years from scratch, and what guarantee do you have that the new code won't have just as many bugs?

 

In fact, given the obvious lack of skill of the Outlook programmers who retain the mistakes of earlier versions, I don't think that even the author of that argument would think that having the same guys rewriting Outlook would do much good! In cases like this, I would find a handful of more experienced programmers and charge them with quiet, continuous improvements to the existing code base. I would give them a large block of time to improve code during which no new features were expected or permitted. A few months, though, not the two or three years that a rewrite would require.

 

SMS: Another interesting point was raised in reference to bloatware. One respondent on Slashdot stated that:

 

"Optimization is not merely about reducing run times or footprint, it also is about choosing the right design and architecture. If you have a program where a given feature is used >1% of the time by >1% of the users and you keep it in new version, you have "non-optimized" code. Giving marketing droids free reign to include features leads to bloatware products like Word and Excel, where even MS acknowledges that most users NEVER use most features."

 

What do you think of this argument? Do you think a product like Microsoft Word would benefit by having every feature that is used by 1% or less of the installed base removed from the product? As a "marketing droid" we have our own opinions on the issue, but we'd like to hear yours.

 

Joel: Well, most people with encyclopedias only look up 0.01% of the topics in the encyclopedia. But would you rather have the Encyclopedia Britannica or would you rather have a lightweight brochure containing the top 100 topics? (You might answer: on a camping trip, I'd rather have the lightweight brochure. Fine. Get the brochure for your camping trip. But at home, where all that 'bloatware' isn't actually costing you anything, you want the full edition.)

 

Or, here's an argument that even the youngest slashdotters will understand. The WWW is bloatware. Finding things is impossible because there's so much stuff out there. Think how much hard drive space is wasted on all kinds of web pages that only .00000000001% of the world ever reads. Since the vast majority of people only go to Yahoo, Ebay, and MSN, wouldn't the WWW be better if it only had Yahoo, Ebay, and MSN? It would be much more "optimized."

 

As you and I both know, though, the market continuously and reliably votes for bloatware with their pocketbooks. If you're trying to sell software, ignore this fact at your own peril.

 

SMS: Yes, we actually have never seen a situation where the addition of new features to a commercial product ever hurt sales (as long as the features worked as advertised). We have seen instances where obscure capabilities in a product "disappeared" due to design changes or simple oversight. We have discovered the screams and yells of people whose favorite little fillip is now gone from their favorite product or service can make a mighty clamor that belies their 1% status. But that's real world thinking.

 

To continue, in the interview we touched briefly on the natural tension that exists between the development and marketing/sales side of a software company. Several people in the Slashdot thread seem to have faced this situation, and in some cases had diametrically opposed viewpoints. For instance, one message stated that:

 

"Too many of my execs (except, for some reason, the VP of Development) are engineers. This leads to a whole host of problems: Many of them tend think they're smarter than people in non-engineering roles. Pursuant to this, they don't think PR and marketing and sales are "hard" or really even "important". Again after #1, they're always right when in disagreement with marketing or sales guys. Most of them haven't developed in a decade+, so now they know just enough to be dangerous -- make micromanaging decisions about detailed subjects things they don't understand well enough, chase unnecessarily after bleeding edge tech, etc. Fail to understand that not everyone wants to always work 14 hours a day. Laugh off meetings, so that eventually nobody in the company knows what's going on.

 

As a result, nobody's heard of us (no marketing budget, no trade shows, no nothing) and nobody's buying our products (engineers tend to make lousy sales guys; despite what they might believe, nobody wants to listen to a 3-hour ridiculously detailed presentation on your product).

 

On the other hand, we have this counterpoint:

 

"I was in a company that was run by technical people, but when the company ran into financial trouble, decided to become more "market oriented".

 

They hired a bunch of professional executives, marketing people, etc. Marketing was put in charge of determining product direction, as they knew what the customer wanted.

 

Well it turned out that the technical people were in fact smarter than the marketing and PR guys, who seemed to think that software could be created by committees and meetings and lots of vision. The company sank like a rock."

 

Somewhere between these extremes there must be a happy medium. Any ideas on how to create it?

 

Joel: I think that the successful technology companies are the ones that manage to develop a leadership with both sets of skills. It's very rare to find them in the same person, but when you do, you get Bill Gates, or Steve Case, or Jeff Bezos. Another solution that may work for a while is to find one of each and have them run things like a bipolar star -- Quark's Gill and Ebrahimi or Apple's Wozniak and Jobs come to mind; the trouble is that bipolar stars are kind of unstable. So when Gill and Wozniak left, their respective companies got a bit lost technologically.

 

SMS: Slashdot, as you know, is a citadel of Linux True Believers, and this operating system and movement have certainly gained media attention and interest in the last few years. The thread devoted to your interview made many many references to Linux. Now, Linux has certainly gained some traction in the server side of the software industry. However, to date, as a desktop OS and competitor to Windows, it's been a bust. Do you think Linux can ever compete with Windows on the desktop? What would need to happen for it to do so?

 

Joel: The good news is that a lot of stuff I write about UI is starting to have an impact on the Gnome and KDE people. There's a lot more appreciation for the value of good UI than there used to be in the Linux community. Once every open-sourcer has seen their marriage break up by installing Linux on their non-technical spouse's computer, they'll finally understand that, no, most people don't prefer command lines.

 

But due to chicken-and-egg problems, running Windows apps is probably nonnegotiable for most people, so WINE is going to have to get a lot better before Linux is a threat to the desktop. I sort of expected with all the effort Corel put into it, it should be there by now, but they seem to be as far as ever from seamlessly running Win apps. (By the way, a lot of people think that the Windows API is too much of a moving target for WINE to catch up. As a Windows developer, let me say, this is rubbish. Almost every Windows app out there is tested on Win 95 to make sure it runs decently on the entire 32 bit Windows product line. If WINE could ever catch up to Win 95, they would be almost completely done. The target hasn't moved anywhere since August, 1995.)

 

Linux is a great server OS, and with some UI work, it would be even better. (Yes, people still pay extra for NT on their servers because the GUI admin tools are much easier than itty-bitty configuration files each with their own language.) Linux is much more of a threat to Sun than Microsoft.

 

I honestly think that Sun's Solaris platform does not have much of a future. They will see their market share shrinking to the rarefied world of mainframe-class machines while Linux steadily erodes from below. And if Sun abandons Solaris to start selling Linux boxes, they're just making commodity boxes, which doesn't justify Sun's current cost structure.

 

SMS: Joel, our last question. One Slashdot'er believes you are " not a programmer, just a marketing weenie who knows C." True or false?

 

Joel: Well, I write code every day, and have done so for most of the last 20 years. I think this is pretty self evident if you read what I write on my site, but slashdotters are not exactly famous for reading the things they are commenting on!

 

SMS: Joel, again, thanks much.