On the other hand, there’s Microsoft’s reliability history, or lack thereof, to consider. Already, a leaked Microsoft memo complains to development teams about the absurdity of having customers pay hundreds of dollars for an operating system with 63,000 known bugs!

The comparison I would make is to running spell-check and grammar-check routines against the articles that I write. Almost every technical term gets flagged as invalid. All of the maddeningly cutesy made-up company and product names that are so common to the computer industry, also get flagged. Finally, because the grammar-checker "thinks" that my style is too informal, it flags some of my more user-friendly phrasing.

These are, of course, in addition to the real spelling and grammar errors. Since these routines are not infallible, they also miss some errors. I suspect the same is true of the results of Microsoft’s scanning program. The memo even refers to a lesser number of "real" known bugs of somewhere in the 21,000 to 28,000 range (depending upon how you interpret the memo), while encouraging the development teams to get that total down to zero bugs by the "next" release.

Huh? Do you want to run that by me, again? Bugs that are, by a rather obvious implication, fixable, are being left in until the "next" release? Is this just to meet some arbitrary release date (which Microsoft claimed it wouldn’t do), or is it to provide further motivation to pay the price for a future upgrade (which Microsoft also claimed it doesn’t do)? In my past experience in both corporate and freelance programming and programming project management, allowing known bugs to get published was grounds for firing.

I’ve already taken a major financial hit by being blamed for the bugs in Microsoft’s 9x series of products. The typical reaction is "Microsoft couldn’t have been so successful with programs that are that buggy." I also get "It can’t be that buggy because someone would have already sued them out of existence for that bad a program." I really don’t want to go through the same thing with Windows 2000.

Luckily, reports from the field indicate that Windows 2000 is less likely to crash when compared to either NT 4 or Windows 98SE. It seems that most of those outstanding bugs are not being hit on a day-to-day production basis. Still, I would suggest that you seriously consider waiting until at least the first full service pack is issued before you implement Windows 2000, especially one of the server versions.

Of course, there is a strong temptation to churn my clients. I am using "churn" in the same sense that it is used in the stock trading business. There, it is used to denote stock sales made simply to generate greater transaction fees for the broker. I’m using it here to denote upgrading or replacing a client’s operating system simply to generate additional software, hardware, and consulting income.

That has been a popular method for increasing income used by computer resellers of various types over the last few years. I have lost count of the number of potential clients who have approached me with malfunctioning and/or inefficient systems, who are being pushed by their current reseller to switch operating systems. Simply fixing their problems doesn’t seem to be profitable enough.

I am also approached by those potential clients who have been brainwashed by Microsoft (or other software companies) into switching operating systems just to "keep up" with industry trends. In some cases, upgrading was justified on a business-decision basis, though not necessarily to the product that they originally intended. More often, the "gee-whiz factor" just wasn’t enough justification for an expensive upgrade. Note that this applies to upgrades within the NetWare family of products, too.

While Windows 2000's server versions are still not as good as Novell’s NetWare (even after the bugs are fixed), they hold the promise of being the first Microsoft-based servers that I can ethically recommend as a reasonable alternative. I still won’t recommend switching just for the hell of it. Active Directory, for instance, in its eventual final form, with all of the bells and whistles added some time in the future, won’t be as good as Novell’s NDS is today. (Read the reviews if you don’t believe me.)

Even if you have a special application which must run on Windows 2000, Microsoft (and virtually all application software developers) recommend that you put it on a separate Windows 2000 server all by itself. In that case, you still don’t have to switch any of your current NetWare servers to Windows 2000 (including doubling up on memory and quadrupling processors in order to maintain the same relative performance).

For those already running NT 4, the upgrade decision depends on whether you absolutely have to have one of the new features in Windows 2000. For instance, if you have large, complicated system and managing Domains is driving you nuts, switching to Windows 2000 to get Active Directory might be worthwhile. If you are having extreme reliability problems in a specific situation in which you have successfully tested Windows 2000, then it also might be worth upgrading. Either way, if at all possible, wait for the release of more bug fixes. Remember that this is a Version 1.0 product.

Oh, and here’s a quick wake-up call to those Microsoft apologists who keep harping on the alleged "fact" that you can’t write bug-free programs. This is from someone who spent a large chunk of his career being called in by other departments (when I was an employee) and by programming firms (after I had my own company) to review other people’s designs or to actually manage their projects.

Yes you can write bug-free programs. It just takes the proper attitude by programmers as inspired by their management. It’s a little trick discovered many years ago and known by various names, but most commonly as "structured testing methodology." It’s a royal pain in the posterior, but it’s worth the effort.

You can even protect your program from being blown by an unknown future program with which it must interface. You just have to validate any data passed to your program in the same way that an accounting program validates an account number. If you enter an account number that doesn’t exist, the accounting program doesn’t blow up, it merely displays an appropriate message, hopefully in readable English as opposed to some wacky code number. Similarly, you must validate data passed to your program. Then, instead of just blowing up, your program can display an appropriate message, too.

Also, if you allow for replaceable, shared subprograms and program libraries (like DLLs and VXDs), then take the time to write a management program to prevent errors. Windows 2000 is supposed to be way better than its predecessors at this task.