Thursday, January 3, 2002

I spent some time today making Kamidake look prettier. I’ve integrated a fair amount of Eugenia‘s interface, which looks much better than the old one. So, that’s good.

I’ve also worked a bit on End of Summer and my in-development webdrama “Quiet.” So, those are both progressing.

I also became very upset at Saalon‘s diary entry for today. My feelings were purely a result of oversensitivity on my end — Saalon is attacking what he sees as my opinion, not me — but I still feel a need to respond.

Now first off, I should point out that my initial statement was that my experiences with the Kamidake upgrade “proves” Joel’s theorem. I was wrong. It didn’t prove Joel’s theorem; it merely provides evidence supporting the theorem. However, Saalon discusses deeper issues, some of which I’ll tackle now.

Saalon’s argument is that Joel Spolsky‘s philosophy, “Never rewrite large amounts of working code, unless you absolutely have to,” is a form of corporate laziness. The corporate solution is to “Put in the least amount of work, and collect the checks,” Saalon’s entry suggests.

Well, let’s look at Spolsky to see if he advocates this attitude. In the (as Joel puts it, “highly irresponsible, sloppy”) Joel Test, and his article on Getting This Done When You’re Only a Grunt, he advocates implementing sensible processes — like version-control software and a bug-tracking database — even when the work is being done without them. In other words, it’s worthwhile to set up daily builds of your software, even if you dont “need” them to get your work done. This advice would surely make a lazy programmer choke on his caffeinated mints.

Joel also writes somewhere of a library that was so screwy that his team went in and re-worked the entire thing line-by-line, rewriting some parts of it from scratch. Unfortunately, I can’t find that post on his site.

So, Joel doesn’t believe in eliminating any and all work wherever you can get away with it. So, what does he believe?

Simply this: Rewriting working code from scratch isn’t easy. When code is rewritten, bugs are introduced into the new code. New code is not guaranteed to be any more stable than the old code. And the old code at least worked. In fact, the old code has (probably) run through the gauntlet of an entire userbase. Bugs have been found and fixed. New code has to be not only written, but also designed and tested. And the new code is supposed to at least work the same way that the old code worked (hopefully better, but it’s OK if it works the same).

Does this mean you should never rewrite any code? Obviously not, and neither I nor Joel would suggest this. This is a theorem, not an ironclad rule. This applies to large amounts of working code. It’s better to write a new product (or library, or whatever) than try to reinvent the old one.

The end of Saalon’s post argues that software quality is important because a quality product is what we leave to the future. I agree totally. That is, I think, an important aspect of Joel’s theorem: that rewriting large amounts of working code from scratch typically descreases the quality of the product. It introduces bugs, and the time taken to fix these bugs typically does not make up for any ease in maintainability gained by rewriting the code, if indeed it ends up being any more maintainable.

Heh. Now I’m sounding cynical.

Now, I want to address a mindset that came to my mind as I read Saalon’s entry. I’m not saying that Saalon believes this; merely that his entry reminds me of this mindset.

Specifically, I want to discuss the mindset that corporations don’t care about quality (to quote Saalon’s entry: “I’ve heard these ideas before…’Only do work if it produces enough dollars to make the work worth it.’ Oh, so having pride in the products we produce is trivial, then?”). Every software company that I’ve worked for has cared deeply about the quality of its software. Besides considering the official corporate line, which has always prized quality, I’ve found that programmers tend to be very touchy about their creations. Programmers feel pride in writing a particularly elegant function or useful library. This translates into a direct concern over the quality of the software.

And now that I think about it, corporate software (I’m thinking of the shrinkwrapped variety) tends to be relatively high in quality, once one thinks beyond petty complaints (“But it doesn’t support Works 2.5 for Windows 3.1!”). When I think of low-quality software, I tend to think of certain shareware and freeware apps I use (which is fine; that’s the nature of shareware and freeware software). While low-quality shrinkwrapped software certainly exists, I can’t bring myself to believe that the corporate software world suffers from low quality any more than shareware or freeware authors.

And I don’t know where I’m going with this now. I do know that my own opinions on software development have been in a frightful tangle for years. Heck, I probably hold several opinions that contradict each other.

In other news, I’ve set up a new poll about boring sports. Here are the results of the last poll:

There’s also new anime music to download: “One-Winged Angel” from Final Fantasy VII.