Microsoft Office 2004: A Product Vision Study
As I write this essay it's January, 2002. What should Microsoft have accomplished with its Office Suite by 2004? Read on and hear one "expert's" opinion. It is my contention that MS Office has stalled as the pace of innovation slowed with the demise of the Office Suite Wars. I provide my analysis of this slowdown, together with my views on what they should build next for the Office Suite. As a shareholder, I have a vested interest in seeing Microsoft keep the Office product line vigorous so that customers feel it is worthy of their upgrade dollars.
What should be done?
My proposal is in several parts. This is very normal--Microsoft itself follows this kind of recipe of building up feature concentrations in various areas. I propose that by 2004, there should be time to do quite a lot. The areas of concentration I would focus on include two standard refrains that appear in almost every Microsoft release--Usability and Internet functionality. One area they are talking about more and more--reliability and security. And two entirely new areas of my own devising--Instant Results Computing and Office Enterprise. Let's explore each one in turn.
Reliability & Security
Of late, Microsoft is working hard to combat the image that Windows software crashes a lot and has a lot of security holes. There's a whole raft of features in the Office XP suite that tie into this theme, and Windows XP itself is largely sold on this promise. Gates himself has made fixing the security holes "job one". I've no problem with it, although from my perspective its mostly people inside the computer industry who compete with Microsoft that have made reliability such a big deal. Corporate IT people like to bring it up as a "Total Cost of Ownership" issue. They want PC's to be "fire-and-forget", so that they never have to go back and fix a problem. More power to them, but the idea that platform X (where X is choose your favorite Windows alternative) is hugely more stable than Windows is largely poppycock.
I hear, "I use System X (usually some Unix flavor) and I never have to reboot my machine." Isn't that just special? But I also see constant evidence of database servers and other software on Unix that need to be "rebooted" (ever see what happens when a log file gets too full or some other malady strikes down Oracle?). Don't even get me started on Macintosh reliability vis-a-vis the PC. Suffice it to say that XP is a great stride forward, more work can be done, but that I don't view this as a burning issue so much as a need for Microsoft to turn the tide of popular opinion back in their favor on this issue and douse some of the hype put out by competing platform vendors and pathetic Bill Gates wannabes. Thank you Scott M and Larry E, for example.
In short, no further action required here from a big new technology or product vision point of view. Microsoft just needs to do some the blocking and tackling to plug these holes, and hopefully Corporate America will be mollified. Security problems will still occur because this is the platform every two-bit (hey, that's a pun!) Information Terrorist wants to attack. But it shouldn't be too difficult to make these hackers have to work hard to get a result. Today it's much too easy to create viruses like nimba.
Incidentally, I'm told by a Microsoft architect that the primary reason for unreliability in Windows is DLL's. DLL's cause problems from three aspects. First, if you get a piece of software hooked up to the wrong version of one because some other piece of software installed a different version at a later date, terrible things happen. For software developers to test through the combinatorial explosion of DLL versions is impossible. The only possible good thing to come out of this problem is it is yet another way to force people to keep buying the latest versions of everything, and so helps keep the dollars flowing in the software industry.
Second, there are some funny semantics to DLL's that got put into place long ago where they get to be shared when two users of it are running at the same time. I believe this was done because once upon a time the memory available on PC's for both RAM and hard disk was such that code sharing was highly desirable. This is no longer the case, but the DLL remains a place where programs swap vital bodily fluids completely unintentionally and can therefore trip one another up. In this day of cheap DDR RAM and hard disks that seldom get filled on newer machines code sharing is just not a worthwhile goal. Certainly not in light of all the trouble that's caused. On Unix, each program is more of a well-insulated island unto itself, and this helps stability tremendously.
The third and final issue is with device drivers. These are not plain old DLL's, but they're a similar concept, only worse. Device drivers have to get right down into the guts of the operating system if they're going to be efficient. If something goes wrong with one, the OS can recieve fatal shrapnel in the process, and suddenly you have a crash. I have a hard time seeing this as strictly a Windows problem. You do like having all the hardware to choose from, don't you? And you want high performance for games and the like, right? Nevertheless, it would seem that Microsoft needs to implement a more rigorous testing standard. I sympathize. The engineers and powers that be at Microsoft are going to want to blame these problems on the device driver authors, and they are usually right. But customers just want the thing to work, and as the holder of this lucrative monopoly, I feel Microsoft has a moral obligation to invest. They should produce awesomely vigorous device driver validation test suites and force manufacturers to run the gauntlet to be certified. XP is making moves in this direction, I notice, so I suspect we're all on the same page.
While I'm on this subject, Microsoft has done some pretty stupid things in the name of improving security as well. At some point, it was decided that emailing someone a web link posed a security threat. If I use the File Send Link command in Internet Explorer, rather than just packaging the link in a message, it wraps it all up as an attachment, and issues a bunch of disclaimers about how this is a security threat. The recipients now have a couple of problems. Firstly, they may not even be able to deal with my Outlook attachments correctly if they aren't using Outlook. Second, their corporate Exchange server may prevent them from opening this type of attachment for security reasons. Worse, I've sent these to friends and their Outlook settings literaly stripped and discarded the attachment. When you consider that I can just cut and paste the URL and send that without all of this drama, you have to wonder what it is that Microsoft has accomplished here other than to create a nuisance for their users. Even were they to plug this hole, given that someone can just type the URL into their browser, its hard for me to see what good they're accomplishing. This was misguided and should be reversed.
The real problem is all the automation and scripting. It simply should not be possible for an email or a document to arrive with a virus that if opened immediately infects. Again, this is a pretty simple problem to solve. If we don't want to disallow said emails and documents altogether, why don't we sign them the way we do downloaded code snippets. You are presented with a certificate telling you who sent the object and that it is a program wanting to run on your machine. You can let it run, kill it, or tell the system not to even bother asking about future programs from the same company. Since this technology already exists in other contexts, how hard can it be for Microsoft to build in?
All material © 2001-2006, Robert W. Warfield.