On reliability and reputation

I recently worked on a couple of software projects that emphasized to me the importance of software reliability. Strangely enough, users expect software to work—and they should. Nowhere is this expectation more evident than in the enterprise, where high availability is a well-known and expected quality. When I think of software reliability, I remember that scene from the movie Excalibur in which Merlin asks the knights of the Round Table to name the most important quality of knighthood. After receiving several well-intentioned but mistaken replies, Merlin replies that the answer is truth.

Although not quite so noble as truth, the most important quality of software products might be reliability. If software isn't reliable, users can't trust the systems they work with. This distrust doesn't end with the system but creeps into the user's perception of other software, and, finally, of MIS in general. For product vendors, unreliable software can cost customers and sales. For MIS departments, it means lost jobs if user dissatisfaction gets out of control. In both cases, people will certainly waste valuable resources repeatedly dealing with known problems.

Reliability, or the lack thereof, has been the thorn in Microsoft's side since the company introduced Windows 3.1. Windows 9x merrily carried this tradition forward. Users take for granted—even expect—system lockups and other problems. But Windows NT stood in sharp contrast to this precedent. The NT development group widely advertised its goals of reliability and robustness, and NT gained a good reputation even at the expense of features and compatibility with older applications. Business users understood and appreciated this trade-off. By changing NT's name to Windows 2000, Microsoft guarantees that the next version of NT will face needless challenges by associating the new name with the Windows 9x problems of the past.

The next release of SQL Server might face this same challenge. SQL Server 7.0 has justifiably gained a great reputation for quality. However, Microsoft tends to name all its products after consumer desktop operating systems. For example, the next version of Exchange is Exchange 2000. I won't be surprised if Microsoft names Shiloh (the next release of SQL Server) SQL Server 2000. But that name can only hurt the adoption of SQL Server in the enterprise, where it must compete with the likes of Oracle and IBM's DB2. It's no mystery why IBM named all its enterprise-level database products DB2, even though each platform's products have different code bases. With this naming scheme, IBM ensures that its enterprise-worthy products are strongly associated with its enterprise-level reputation and reliability. Although I'm sure Microsoft marketing understands the home consumer market, maybe Microsoft could still learn a few things from its enterprise-level competitors.