Before I get started, I suppose some sort of introduction is appropriate for readers who have only recently discovered that some of us in the Mac BU are bloggers. I’m Rick Schaut. I’ve been blogging since February of 2004. Here is a short bio I wrote about myself back then. I’m currently the lead developer on Microsoft Word for the Macintosh. I’ve been with Microsoft for more than 16 years, and the first product I worked on was Mac Word 5.0.
A couple weeks ago, I had the rather interesting experience of interviewing the person who hired me to work at Microsoft all those 16+ years ago. This person has been away from Microsoft for 13 years, and my role in the interview loop was to provide some background on what has happened with Mac software development here at Microsoft during those 13 years. Since many of those thoughts are fresh in my mind, and because the substance of that conversation involves the main reasons why Mac BU exists in the first place, I thought I’d share some of it with you.
Thirteen years ago, the overall software development philosophy at Microsoft could be characterized by the concept of “write once, run anywhere” that we’ve often heard used in conjunction with web-centric technologies like Java. It even involved some of the same concepts, like p-code, for example. At the time, we believed this was the most efficient way to maximize user benefit for a given amount of development effort. Users got the same features regardless of their platform of choice, and they got more features. We didn’t have to implement those features for each platform.
Along the way, particularly in the case of Mac Word 6.0, we discovered some inefficiencies buried within that philosophy. These inefficiencies fall into three broad categories, and I’ll talk about each in turn. They involve the software development process itself, differences in platform technologies, and differences in the needs of users as reflected in their choice of computing platform.
Most issues involving the software development process itself revolve around ideas explored by Fred Brooks in The Mythical Man Month. In short, there’s a point of diminishing returns for the number of features we can add to a product in any given ship cycle. The more features you add, the more time and effort you have to put into integrating those features. Time spent fixing bugs increases disproportionately to the number of features you’ve added. Doubling the number of features you add in a ship cycle, for example, can triple the number of bugs you’ll have to fix. The “write once, run anywhere” philosophy is inherently self-limiting in terms of efficiency.
That philosophy also precludes taking advantage of platform-specific technologies. “Write once, run anywhere,” means writing code to a least common denominator, and locks you into a set of interface guidelines that might not be appropriate for one or more of the platforms you’re targeting. You’ll get to see some good examples of this in the way Office 12 makes use of Quartz both in terms of its user interface and in terms of some of the things you’ll be able to do in documents, presentations and charts.
Lastly, and probably the most important problem with the “write once, run anywhere” philosophy is that you lose the ability to target different groups of users in terms of the way their needs are reflected in their choice of computing platform. Mac users are not Windows users, and that’s not just a difference in aesthetics. You see these differences when you segment the various markets. Someone who does freelance graphics arts work, for example, is very likely to own a Mac. Within the enterprise, Mac users tend to be clustered in advertising. While not universally true, there are distinct, broader tendencies that imply different needs.
Put all that together, and you come up with the decision we made back in 1997. The group of folks developing Mac Office needed to be serrate from the group developing Win Office. It’s a good, viable business with a different set of opportunities than the Win Office business. It’s almost a no-brainer.
Since then, however, we’ve discovered a rather interesting synergy that’s come from having two development groups targeting different users on different platforms with the same general software solution. Because the Mac Office and Win Office groups are separate, we’re free to explore certain ideas in different ways. One example of this is context-sensitive UI. Mac Office explored this idea in 2001 with the formatting palette, and Win Office 2007 takes this same idea into a different direction with the ribbon. We’ve taken the ribbon idea into a slightly different direction, as you’ll see when Mac Office 12 ships.
In short, while having two separate development teams for Win Office and Mac Office might seem, on the surface, to be a very inefficient way to develop very similar suites of applications, it turns out that there are considerable benefits. A vast majority of those benefits accrue to you, the user. Personally, I rather like it that way.
Currently playing in iTunes: Days of Old by Eric Clapton & B.B. King