Saturday, December 20, 2003

Telirati Newsletter #25

In this rant, I let rip on what was, in 1998, Microsoft's inability to make the NT elephant dance. The fact that now we all use NT - in the form of Windows XP - is a huge credit to Microsoft's abilty to execute.

Telirati Newsletter #25: Microsoft’s soft underbelly

What’s wrong with Microsoft? Not much. Expect NT to continue to consolidate the victory it has already scored over Unix and NetWare as a server platform for mainstream business server needs. Expect Windows 98 to be a winner in the upgrade market despite the usual grumbling gurus that say “don’t tamper with a working Windows 95 system.” Expect Windows CE to start taking off.

But don’t forget that not everything made in Redmond turns to gold. Bob and At Work clunk the loudest when you shake the box, but there are incremental losses as well. Predicting such troubles is an extremely dicey business. To give you an idea just how dicey, I not long ago said that a particularly likely peril of perdition lay with Java, and Microsoft then corks it with Visual J++ 6.0. But it can still be instructive to look at the places where Microsoft skates on thinnest ice.

Compaq now owns Alpha, Digital’s CPU architecture. Alpha languished at Digital because it is a 64 bit chip running 32 bit NT. Yes, it runs 64-bit Unix, but that had little impact (which says something about Unix, but that’s not today’s topic). Merced, Intel’s new architecture, is also a 64-bit chip, not due until 1999. I could hear something that sounded like a huge sigh of relief emanating from Microsoft when Intel announced Merced would be late. The brave announcements that Microsoft would have a 64-bit NT ready for Merced, right on the heels of NT 5.0, never sounded very convincing, and look less so as NT 5.0 slips, and other aspects of NT 5.0, like Wolfpack, get scaled back in ambition.

If the lack of 64-bit NT hurt Digital so deeply, what would the presence of Merced do to Microsoft if they are not ready with 64-bit NT? This question assumes Merced can drive OS decisions, an assumption unlikely to be universally true, but serious enough to be worth asking. Speculation that this will hurt Microsft is already n the trade press.

It is also worth asking why is NT so late. It is because NT is not like most Microsoft software. What? Isn’t NT the very definition of Microsoft software? Isn’t NT the destiny of all PC software at Microsoft? No, and not necessarily. NT was for many years the most alien presence inside Microsoft, and only recently has NT and the rest of Microsoft begun to converge on a single philosophy. NT is big, unfriendly, and hard to deal with. It is less unfriendly than and less hard to deal with than NetWare, which is why it is sweeping NetWare from the playing field. But taken on its own, NT is no joy.

Contrast NT with Windows 95, which was a ringing success in finally delivering on the promise that a Macintosh-like GUI environment could be created on PCs. The easy part was making a windowing environment about as good as the Mac’s. The hard part was making installation of software and peripherals as easy on PCs as it is on the Mac. This latter success was won on the basis of brute-force hard work, and deserves a newsletter of its own to tell the tale. Windows 95, for all the compromises and architectural awkwardness of a system that has to carry the considerable deadweight of a DOS legacy, went beyond Macintosh is delivering a consistent, object-oriented, 32-bit programming environment that spans client and server systems to PC. No small achievement. Where was NT when Windows 95 changed the PC world? To be fair, without the development of the Win32 APIs and COM on NT, Windows 95 would be rather less revolutionary. But NT did not pay much attention to making the customers life easy. The Windows 95 user interface was adapted to NT with NT 4.0. The miraculous level of hardware compatibility found in Windows 95 has not come to NT yet.

What marker can one seek to measure the distance between Microsoft’s consumer OSs and NT? Windows 95, and now 98, are sold to any Tom Dick and Harry with 90 bucks and PC. This customer is likely never to open the documentation. NT is served by a priesthood of MCSEs, geeks who have taken courses to master its complexity. So, while superficially, one might get sucked into thinking that, after this product generation, NT could entirely replace Windows 95/98, the divergent cultures of these two systems will have to be reconciled through a tremendous amount of work before the blessed event of one PC OS will ever happen.

Let us take a moment to consider this MCSE thing. Certified geeks to operate computer systems is an idea Microsoft copped from Novell, which had long made scandalous sums of money training and certifying people so that they could successfully install and operate their product. This might make some sense in a world that thought of computers, at least of servers, as some type of industrial equipment. You would send your machinist to a training course to learn about his new lathe. But computers have advanced beyond this stage. In the previous newsletter I covered small servers. If nothing else, small servers indicate that, in order to sell lots of servers, they have to be at least as easy to buy, install, and use as desktop PCs. Whereas a culture that encourages semiprofessional certification as an indication that a person can use a product means that product is not ready to be used by the general public. Microsoft product managers could respond to this with reams of white papers and presentations that would tell you that the complexity of Windows NT can be either hidden or encapsulated, and that not everyone would need to learn the complexity of the system or to access every feature. Don’t believe it. Dry feature lists and usability studies do not capture the essence of the problem. Not until the culture of trained system operators is not only obsoleted, but actively denounced and overturned will NT be ready to replace Windows 98 as an OS for everyone.

Back, then, to the root of trouble: It is the culture within Microsoft that produced the culture among users that requires trained operators that is the greatest risk to Microsoft’s future. This is for Microsoft, what comes after their successful response to the Internet. The next task is to internalize and weave into its institutions the fact that sauce for the user goose is sauce for the administrator gander. The people running systems deserve at least the same level of effort that goes into making a writer’s, or a Web designer’s, life easy in outstanding products like Office and FrontPage. When there are lots of servers, there won’t be enough administrators. Users, customers, will be administrators. It is therefore useless to think in terms of better administrative tools if there is no one to learn those tools. This is the question: Can Microsoft make servers customer-friendly? Not administrator-friendly, but customer-friendly. Customer-who-runs-a-business-not-servers-friendly.

Big OS upgrades are a dangerous undertaking. Failure of big OS development projects caused the fall of Novell and Apple. For Microsoft as well, there is a simpler danger than the complexity faced by customers, which can be papered over in the short run. NT 5.0 is late. And while Microsoft, not less, and often more than some other software organizations trumpets their methods and controls that make it possible to undertake huge software projects, the reality is that isf these methods worked as advertised, projects would not go late. Is adding pressure to simplify the user experience just going to make OS projects even more complex, and therefore more late?

While it is too late for NT 5.0 to benefit from a re-think, it is worthwhile to examine whether user-hostile administrative interfaces and late projects are somehow linked. How could these two factors interact? Take, for example, configuring NT. In theory, NT server and NT workstation are one OS configured only slightly differently. In practice, the set of NT server facilities that enable networks of workstations to operate securely and in an orderly manner are what make NT server different from NT workstation, and it is impossible for the average computer user to understand these services and, especially, how these services are intertwined as they share information about users, servers, security, etc. If there were a visual tool, not an ugly pile of dialog boxes that only serve to format obscure textual information rather than interpret and represent it in graphical form (they do call it a graphical user interface, which should be a broad hint to interface designers), to manage configuration, that would be progress. In order to make such a configuration and management tool safe for users, modularity, consistency-checking, and error handling would have to be raised significantly above the level it is today in NT management tools.

Take this simple datum as an indictor: in most administrative tools, there is no “undo” operation. Start with that, and then implement every ease-of-use enhancement since 1984 and you will have raised administrative tools to something like what the average marketing drone gets with PowerPoint. Then go a few steps beyond that, and the average PowerPoint user might then be able to install and operate a server. This is one way to express the goal of simplification, and not a fatuous way either. That guy with the PowerPoint slides is your server customer. And that server customer won’t be able to hire a technician for his server. And that technician makes ever less economic sense as server prices fall.

But back to the synergy with server development. For all the gasconading about rigorous development methods, which do you think might impart more discipline on the process: More management controls over the development process with more bug-counting and code metrics, or the discipline of having to make NT installable, manageable, and configurable by the average PowerPoint user. If Microsoft made NT the way it makes products for real human beings, it would not only benefit the customer, it would make NT development more connected to disciplines that matter in making quality software in ways that software project management methods seldom adequately capture.

Copyright 1998 Zigurd Mednieks. May be reproduced and redistributed with attribution and this notice intact.