You Don't Need Word

Back in late August, my article on the Anatomy of a Software Bug got slashdotted. That prompted John Mitchell to post this missive over on artima.com. John and I had a brief exchange back then, but that was early September—right about the time when my workload became such that I couldn’t really follow up on some of the issues raised in that discussion. Having a bit more time on my hands, I want to try to resolve them, or, at least, clarify a few points. This also serves as a good follow up to my earlier post on Word’s automated features, “Let Word Do It.”

John claims that we’ve become addicted to “complicatedness,” that there is some pathology that leads Microsoft, and other software vendors, to make software more complicated than it should be. While this is a very interesting thesis, indeed managing software complexity the substance of a number of debates within various academic circles under the general rubric of software engineering, John’s position on this has both a flaw in logic and a dearth of objective data to support it. I’ll discuss the lack of objective data first.

Every piece of software represents a particular solution to a mini-max problem. What’s a mini-max problem? Well, it’s a problem wherein one tries to maximize some outcome within a set of constraints that operate contrary to the outcome one is trying to maximize. The constraints tend to minimize the outcome, hence the term “mini-max.” There’s an entire field of study, known as “linear programming” that’s dedicated to finding efficient ways to solve such problems.

While linear programming has given us a number of very effective tools to solve mini-max problems, it requires quantifying both the desired outcome and the constraints, and herein lies one of the fundamental problems of developing a piece of software as a product for general consumption. The thing we’re trying to maximize is a subjective quality known as “user satisfaction.”

Right about now, at least some of you are saying, “What on earth are you talking about? It’s trivial to measure user satisfaction. J.D. Power and Associates does this all the time. All you do is develop an effective survey.” In essence, John says the same thing when he suggests that, “the proof is in the pudding.” While I might take issue with John’s particular formulation of that survey, which consists primarily of asking how many people curse the product, there is an even more fundamental problem with this approach.

Constructing some kind of user survey to measure user satisfaction is great for trying to figure out how well you’ve achieved the goal you set out for yourself, but, by that time, you’ve already made the crucial decisions with respect to the basic mini-max problem you’re trying to solve. While this might lead you to reasonably reach some ex-post-facto conclusions about “complicatedness,” it does absolutely nothing for you at the time when you’re making the decisions about what features you want to put into a product.

There are a number of things you can do, before you’ve actually developed a product, to try and figure out whether or not the particular set of features you’re planning to implement will maximize user satisfaction. I’ve blogged about this before, and we’ve refined the process even further for the next version of Mac Office. I’m itching to talk about some of the things we’re doing, but I can’t—at least not just yet. Nonetheless, it’s extremely difficult to measure the extent to which users will be satisfied with a given set of features until such time as you put the whole package in front of them. This virtually eliminates any possibility of objectively comparing completely different sets of features in terms of user satisfaction.

At some level, I think John recognizes this problem, because he introduces the notion of figuring out the difference between what users want and what users really need. Herein, however, lies the flaw in logic in John’s thesis. The word “need” simply doesn’t belong in any discussion about technology. Any attempt to inject the word “need” into a discussion about technology involves drawing an arbitrary, and often capricious, line between certain sets of features. Regardless of where you decide to draw that line, the mere act of drawing it amounts to begging the question.

Technology is entirely about something called the “value proposition.” At some level, every product, even products involving basic needs like food, shelter and clothing, involve a value proposition. Technology, however, has a fundamental difference from most other products in that technology involves a value proposition that many users don’t perceive for themselves until they start using that technology.

How many times have you used a particular piece of software for a while only to start wondering how you ever got your work done without it? How about specific features in the software you use? Yet, if you sat down and really thought about it, you really don’t “need” either the software or the particular set of features that you’ve come to perceive as being indispensable. You, like everybody else, use any given piece of software because, for you, that software presents the maximal value proposition relative to anything else available on the market.

In the brief discussion I’d had with John over on artima.com, I pointed out one rather undeniable fact: that Word is, by far, the best-selling word processor on the market. When I pointed this out, John said that I can’t have it both ways—that I either sit up and take notice of the fact that a number of people curse Word, and thereby take steps to simplify the product, or forever consign myself to some pathological addiction to “complicatedness.”

If this is the case, then Word has succeeded despite itself for reasons other than the basic notion that Word, despite all its funky quirks, still represents a maximal value proposition for the vast majority of people who buy word processing software. Nobody needs Word. If I can’t have it both ways, then, I would contend, we are all consigned to a belief that people making software-purchasing decisions are not making rational choices.

Now, some of my more astute readers will have picked up on the subtle distinction I’ve made between users and people making software-purchasing decisions. In large organizations, and even a few smaller organizations, the users are often not the persons making the software-purchasing decisions. I would contend, however, that user productivity represents no small factor in the software-purchasing decisions made in these kinds of organizations, and I really have little doubt that most organizations would drop Word in a heartbeat if they thought some other product would result in increased user productivity.

None of this is meant to sweep Word’s problems under the rug. Nor, for that matter, do I believe anyone can reasonably argue that I am ignorant of these problems. After all, my last post was a poetic tribute to some the very problems that are the substance of John’s thesis. There is still much that we can do to increase Word’s value proposition across the board.

The point of this discussion is to illustrate the difficulty of making sweeping value statements about any software product, and to show, at least in part, how such statements really don’t serve a significant purpose in terms of increasing the value proposition for wider ranges of users. To invoke the clichés, John’s “having it both ways” is my “two sides of the same coin.” If the ultimate goal is to maximize user benefits, then I believe my view is the more effective view. The reasoning behind this, however, is the subject of yet another post.

Rick