Eleven years

This coming Monday, I will have been working for Microsoft for eleven years, migrating from my initial position in Excel development into the newly-formed MacBU (or Macintosh Product Unit, as it was called in those days). I took some time this past week to look through what all I had really managed to accomplish over that time frame, partially wondering whether I was living up to my (self-gauged) potential. It's hard to recall all the little things I did for the various projects; the ship list seems to be the remaining milestones. Fortunately for my memory, those are permanently affixed to the Ship-It awards (I ran out of space on my first one), and I have the Shelf-of-Ship, a display of promotional boxes from the various products shipped (including the somewhat-hard-to-come-by Office 98J CD).

MacBU seems to have progressed a bunch over the years too. I missed the 68k to PPC transition that had happened with Office 4.2, but between picking up Windows components that Windows Office doesn't have to maintain for themselves (OLE, OLE Automation, Visual Basic for Applications), having to switch from our no-longer-supported Macintosh cross-compiler in MSDev to Metrowerks CodeWarrior, and undergoing a major OS revision (OS 9 to OS 10), we've come a long way. Now we get to look at CFM vs. Mach-O, moving to Xcode/gcc and adding Intel to the platforms (and largely the former two because of the latter). Roz has made a public commitment to work on it, and Erik Schweibert, my current lead, has already posted on some of those trials.

At the same time, whereas we don't have to play porting games with Windows Office, as their source diverges from ours, and as we need to maintain file format compatibility (to at least roundtrip the things our code doesn't support), we have a delicate balance to maintain in terms of what needs to get brought over from Windows Office and how it gets brought over: Do we port it and try and keep our code in sync with theirs? Do we clean it up as a v. n+1 version of the same feature? Do we rewrite it in a MacOffice paradigm? Do we do nothing and suffer the consequences? Each of these options has its negatives: Porting/synching code has the problem of many more developers working for Windows Office producing much more code than we have time to carefully review and integrate, and even if we do so, we have to live with the drawbacks of their particular implementation; on the good side, it means that if we have to do more porting of code added in a different release, it'll be easier to do since there will be fewer differences between our code and theirs. Cleaning it up suffers from the same problem of quantity, and whereas the finished product might be better and/or more elegant from a pure code-maintenance perspective, we complicate the future porting strategy — will we still be able to add the new feature they added to our "cleaner" version of the code, or will we have to throw out what we did and go back to straight porting later. (To be fair, it's not strictly a one-way operation; sometimes Windows Office ports code from us, and they face most of the same issues, if not the quantity issue. However, I doubt most of the pure code-cleaning gets back-ported unless it adds significant features; from most people's perspective, all it does is add risk to shipping on time.) Writing a MacOffice-version of the same feature has similar consequences, and when file format is involved, not supporting it is just not an option. Rick Schaut has been posting on the most current incarnation of file format compatibility since mid-2005.

For better or worse, MacBU hasn't been the only Macintosh software developer at Microsoft over these years. During its inception, a bunch of teams offloaded the Mac versions of their code, some with a big sigh of not-having-to-maintain/support-Mac relief. There were (and are) still exceptions... The Outlook team continued to produce a Macintosh Outlook client up to the 2001 edition. Encarta still produced their Mac applications (even though they usually had two developers all told for both platforms). The Windows Media Player team produced their, ahem, client for the Macintosh, though that has been recently supplanted with the Flip4Mac version. (This, by the way, caused a minor debacle, since their PR dept released the information on the same day Roz made the five year commitment.) The hardware group still produced their own Macintosh drivers, and the Services for Macintosh team on Windows Server worked on the Microsoft UAM, which, by the way, seems to have been replaced by an Apple-provided version of the same thing by 10.4.6 that even works on Intel. Included among the new exceptions are the WPF/E project, as well as the cross-platform shared source initiatives. In all of this, these groups are acting as peers, without a specific Macintosh oversight group. The tradeoff is that there's freedom for these teams to do what they need to do for their product, at the cost of a lack of Mac-product uniformity in quality, best practices, access to Apple information (MacBU has the closest link to Apple), and so forth.

As much as the new Intel boxes are creating new work for and my team, they still give me the excitement that something new is always happening in the Macintosh world. I look forward to writing more "interoperable" software, and hope to see another decade of closer Apple/Microsoft integration and partnership.