I spent the day catching up on the Joel on Software translation effort.

There are new articles online in Danish, Dutch, French, German, Hungarian, Indonesian, Japanese, Korean, Portuguese (Brazilian and Iberian), and Romanian.

As my faithful volunteers have learned it sometimes takes me a week to respond to their email; I usually let all the translation-related email pile up and then work through it once a week.

Right now there are a few articles stuck in the queue because they don’t have a copy editor — if you can edit in Farsi, Portuguese (Portugal), Russian, Spanish, or Turkish, please let me know!

Ah! Danny Goodman has released the new version of Dynamic HTML. It’s been a few years since the first edition, which is still the best reference on HTML despite being severely out of date. The new edition is 1400 packed pages that actually tells you what web browsers that are actually in use actually do, which makes it invaluable. It has been brought up to date with all the latest browsers and the newest HTML specs. If you’re working with HTML in any way, shape, or form, this book is an absolute requirement.

Feedback from my posting about FogBUGZ Setup fell into four categories.

“Why make Setup reversable? Instead you should collect all the information from the user and make all the changes in one batch at the end.” There are a couple of things to understand here. First of all, even if you do everything in one batch at the end, there’s always a possibility that some step in the middle of the batch will fail, and in that case, a well-behaved setup program will back out the steps that were already done. There are well over 100 error messages in the string table for FogBUGZ Setup so the number of things that can fail is not insignificant.

Second, it’s not nice to tell people about an error in their input three pages after they made the mistake. For example, early in the FogBUGZ setup process we prompt you to create an account for FogBUGZ to use:

The account creation could fail for a myriad of reasons, none of which can be predicted before trying to create the account. For example, the password might not conform to the system password policy. And different national versions of Windows NT have different rules about accented letters in passwords (betcha didn’t know that!). It’s better to tell the user about this problem right away so they can correct their input rather than having a message come up during the long install process later, forcing the user to back up and fix it. And even if you force the user to back up and fix it, you still have to undo the first part of the work that you did before creating the account, otherwise you’ve left their system in an indeterminate state.

In any case I need to write code to create the account and delete the account in case something later fails; I might as well call that code on this page of the wizard where I can display a useful error message.

And what are the kinds of things that need to be reversable? Well, in order to upgrade FogBUGZ without requiring a reboot (and we never, ever require a reboot), we have to shut down a couple of processes that might have been keeping FogBUGZ files pinned down, such as IIS (Microsoft’s web server). So part one of the batch is “Stop IIS.” Now if part 2 fails for some reason, it would be extremely rude to leave IIS not running. And anyway, it’s not like I don’t need to write the code for “Start IIS” for the end of the batch. So the code to rollback “Stop IIS” is already written. No big deal, I just need to call it at the right place.

I think one reason that people think you should “gather all the info and then do all the work” is because with very large installation programs that are very slow, this is a polite way to waste less of the user’s time. Indeed even FogBUGZ setup does 95% of its work at the very end. But the “create account” operation is so fast, that principle simply doesn’t apply here. Even our 95% of the work phase takes well under a minute, most of which is spent waiting for IIS to stop and start.

“Why did you use VC++/MFC? Surely an advanced intelligence such as yourself has admitted by now that Delphi is more productive.” First of all, leave your language religious fanaticism at the Usenet door. Somehow I managed to figure out in high school that language advocacy and religious arguments are unbelievably boring. 

Secondly, even if Delphi were more productive, the only pertinent question, since I am writing the code, is what is more productive for Joel Spolsky. And I don’t know Delphi at all, but I know Win32, MFC, and VC++ really, really well. So while I might not outcode a good Delphi programmer, I would definitely outcode a completely inexperienced Delphi programmer (which is me), certainly over a short 4 week project. Third, many of the things I needed to do in this setup program are things like “grant the Logon as Service privilege to an account.” This is rare enough that the only way to find out how to do this is to search the Microsoft knowlege base and the web in general. When you search the web in general for how to do fancy things with Windows NT, what you find is about 75% C code, maybe 20% VB code, and 5% everything else. Yes, I know, I could translate the C code into Delphi (assuming I was a sophisticated Delphi programmer, not a completely inexperienced Delphi programmer), but that costs as much productivity as I would supposedly gain from your supposedly more productive programming language. And fourth, I already had about 30% of the code I needed for Setup in MFC format: from FogBUGZ 2.0 Setup, and a library I’ve been using for years to make wizards.

“Why make Setup at all? You already have your customers’ money. Good Setup programs don’t increase sales.” This was actually the smartest question and made me think the hardest. I came up with three reasons:

1. Decreased tech support cost. This setup program will pay for itself over the life of the code.
2. Delight my customers. When I’m trying to get them to upgrade to 4.0, I want them to remember how painless the 3.0 installation was, so they won’t hesitate because they are afraid to upgrade. I’m still using an old version of SpamAssassin that is becoming increasingly ineffective, even though I know the new version is much better, because I just can’t bear the thought of another morning wasted. The very memory of the first SpamAssassin installation — all the little SSH windows, some su’ed, trying to scroll through man pages and Google Groups, accidentally hitting Ctrl+Z in Emacs to undo and having it suspend, trying to guess why we can’t get the MTA to run procmail, sorry it’s too much. If SpamAssassin was making money off of upgraders they would have lost my business because they don’t have a SETUP program.
3. Win reviews. Software reviewers always cast about for some kind of standardized way to rate software, even when they are comparing apples and oranges and planets and 17th century philosophers. They always have a meaningless list of things to review which can be applied to PC games, mainframe databases, web site auction software, and DNA sequencing software. And Setup is always on their list. A single flaw in setup is guaranteed to be mentioned in every review because every reviewer will see it and say “Aha!”

“How can we make WISE better?” Kudos to the product manager of WISE Installation System for calling me up and listening to my litany of all the reasons his product wasn’t adequate for typical IIS/ASP/SQL applications.

Delphi Questions, a new Joel on Software discussion group.

I’ve been snowed under for the last four weeks, working on the FogBUGZ 3.0 Setup program.

 

Eddie Kessler describes programming at Napster.

Ray Ozzie has more on platforms. “Finding the ‘right’ price point for a software platform is critical.” To me this sounds like a fancy way of saying, “I groove all that stuff about how platforms need to be cheap and ubiquitous, but I can’t bring myself to do it.” The price, Ray says, “must be high enough both 1) to maintain a perception of value in the platform, and 2) to create significant margins well before ubiquity is assured so that the ecosystem is assured of the platform’s ultimate viability.” What he doesn’t mention: if you lower the price on the only product you’re selling, you have a revenue hit, which will not make your investors happy, and you may run out of money and have to close. But that must be what he’s thinking.

Dave Winer continues the Platform theme: “If you’re lucky enough to get a gazillion dollars invested behind your ideas, never say no to a developer.” General Magic had a platform they tried to position as an application. (Getting a gazillion dollars didn’t help them much, either.)

I’ve created a new discussion group for .NET programming questions. (Why?)

Let’s hope it doesn’t turn into this.

Orlando Sentinel: “After investing $273 million, NASA is canceling a cutting-edge launch-control computer system for the space shuttle that is over budget, behind schedule and too expensive to operate.”

(A few paragraphs later) “The CLCS program began in 1997 as an effort to upgrade KSC’s 1970s-vintage system.”

Here’s my question. In the 1970s, computers didn’t have much memory. An expensive mainframe from that era couldn’t have had more than a megabyte or so of core memory. It seems to me as if the most complex piece software that could possibly be run on such systems would pale in comparison to the complexity of the software in a modern CDMA cellular phone, also about a megabyte in Assembler code. (I know, somebody’s going to tell me about how mission critical this stuff is, and how lives depend on it, but heavens, $273 million dollars?)

The question is, why are NASA, the FAA, etc. still running these ancient systems, and why have so many quarter billion dollar projects failed to replace them? Jeez, they didn’t even have relational databases in those days, to say nothing about structured program, GUI development tools, and books by Kent Beck. Recreating those old systems with modern tools would probably be a weekend Visual Basic/Access project. OK, I’m exaggerating a little. But if the problem is that you can’t even get parts (vacuum tubes, no doubt) for the old system, you don’t need a zillion dollar Big Science project: you need a four week project writing a CPU emulator for that old mainframe that runs on PCs.

OK, maybe now we won’t be subject to all those annoying lectures about how great SEI Level 5 is because the shuttle uses it. Flipping back and forth between today’s news and that old FastCompany hagiography will keep you entertained for hours!

Ged Byrne points out that it was actually a different system that used SEI Level 5.

Copy Editors Needed!

I have a few articles which have already been translated, but are waiting for someone to edit them and do a final check before I post them.

If you would like to volunteer to edit some articles in any of these languages, please let me know: Farsi, Hungarian, Italian,  Portuguese (Portugal), Ukrainian.

Jakob Nielsen on Offshore Usability: “To save costs, some companies are outsourcing Web projects to countries with cheap labor. Unfortunately, these countries lack strong usability traditions and their developers have limited access — if any — to good usability data from the target users.”

Offshore usability is a specific case of the general “offshore design” problem. Put simply, software teams are not successful when design or management are done in a different physical location than programming. Once I actually had a job where I was in New York, my direct manager was in Singapore, his manager was in Hyderabad, and if I needed any management input I had literally no choice but to go to the CEO because at least he was awake during the same hours as I was. You can’t get things done like this. A good project team relies on hundreds of small interactions a day. Here in the Fog Creek offices, we have 10 small conversations about FogBUGZ 3.0 development every day.

What I don’t understand is people who think it’s OK to move the developers ten time zones away from their managers and expect good results. Those same people would scream bloody murder if you told them that you were going to send the whole management team to Bangalore or Beijing.

John Robb has an interesting perspective on trust-based, targetted advertising based on his experiences at Gomez during the heady days of the Internet gold rush.

Nobody believes advertisements any more. There’s a lot of evidence that advertising just doesn’t work, no matter how targetted, so if you have a product to sell you have no choice but to get into the editorial side, where consumers’ defenses are lowered. Product placements are one example of this.

There is an unfortunate tragedy of the commons, here. When advertising first rose to prominence, advertisements did work. We hadn’t built up our immunities yet. As more and more advertisers used the opportunity of the medium to lie, we learned not to trust advertisements. But we still trust editorial. And once editorial gets polluted by desperate marketers using PR instead of advertising to promote their message, nobody will believe it either.