Incremental mojo

Hello, another introduction for you – my name is Geoff Price, and I’m the Product Unit Manager for MacBU in Redmond. This is MS speak for saying I have responsibility for the core engineering teams here (development, testing, program management and user experience research.) I look forward to contributing to this eclectic RSS broadcast at irregularly scheduled times, and I’d like to echo those who have gone before in thanking you very much for tuning in.

I intend to cover more specific topics about our software, our teams, what we build and why, but first I thought I’d start out (perhaps uncreatively) by filling in some of the background picture on my particular history of development on the Mac and how I got to be here.

My programming experience with Apple computers began on the Apple IIe in 1983, and my development experience with the Mac itself began around the time of the introduction of the Mac II in 1987. (I realize it is possibly more fashionable these days to date your involvement with the Mac all the way back to at least 1982, or some other date even earlier than its actual introduction, but these happen to be the correct dates in my case.)

Back in the day, I worked at a Mac lab in U.C. Santa Barbara, and when student traffic was slow I could use the time to do coursework, experiment with Turbo Pascal, or write political columns for the campus paper (random aside: one of these concerned the case of an amateur talk radio host by the name of Sean Hannity, facing dismissal from the campus airwaves over inflammatory on-air remarks. A story, I suppose, for another blog.)

I soon joined a team operating out of the deeper recesses of the lab that worked with faculty to explore the practical teaching and learning opportunities emerging out of the new “multimedia” technology. In order to rapidly develop courseware applications for interested faculty, this entailed a deep immersion in the enchanting, “hyperlinked”, quasi-object oriented world of HyperCard, which would prove to be a consuming focus for the next several years.

As long-time Mac enthusiasts know well, HyperCard tended to stir fierce devotion in its supporters. At the time, it captured a sense of the creative possibilities of computing, as well as the spirit of the Mac in enabling the rapid development of graphic user interfaces with a more accessible and English-like interpreted language for programming. It also had a bit of the punk sensibility of DIY (if with a highly geek cast.)

This was at a time when Apple was pretty dominant in education, and there was terrific momentum behind HyperCard there. Now, HyperCard was relatively accessible, but it still took some learning and a lot of scripting, and by default had some limitations, especially relative to multimedia. It was however highly extensible, as developers could build compiled code resources (XCMDs) that tapped into any underlying system API, which could then be accessed as commands in the HyperTalk scripting language.

My work on courseware applications led to a partnership with a teacher named Mark Ferrer, who had ideas about trying to provide teachers and students a richer framework for developing their own interactive multimedia applications. The result of this was a HyperCard-based authoring product with a name rooted in academic workshops, HyperGASP, which we eventually released as a small-scale commercial product, touring around schools and colleges and working with interested educators.

One thing this initial foray into commercial software made me appreciate pretty clearly was the amount of work involved and the value of specialized expertise in all aspects of software development. I designed UI, wrote code, tested it, wrote documentation (in a stack, of course), spent time working with reviewers at tech publications, mocked up ads in Photoshop, managed beta lists, handled tech support, etc. You can still read about the product here, conveniently and cryonically preserved on the web. (Funny to go back and read some of that. I forgot about the great Word integration features we threw in – so Microsoft-friendly!)

Ultimately of course, HyperCard didn’t make it. Apple struggled with the business case, the rise of the PC in all segments as well as alternative authoring environments displaced a lot of HyperCard seats, and ultimately the cross-platform standard of the web provided a much more killer framework for hyperlinks. Many creative endeavors that had incubated in and around HyperCard lived on, such as wikis, boingboing, and Myst.

(Quick test for HyperCard gurus lurking in the audience: given that you could only paste cards after the current card, what’s a one line command you could type into the message box which would move a given card (say #n) to the first position in a stack, and why does it work?)

My personal life got busy with the arrival of my first two children. I transitioned to working for a publisher in Santa Barbara who had carried HyperGASP in their catalog, helping them build custom cross-platform multimedia tools. In addition to Mac programming this entailed ramping up on more serious Windows application development (Win32/MFC) as well – something that seemed like a reasonable hedge given the share Windows 95 was establishing.

By the time I dropped an updated résumé off with a recruiting agency at MacWorld Expo, I was resigned to the idea that my next job might end up being straight-up PC programming, or something completely different like Java. Surprisingly, the company that turned out to be most interested in the Mac portion of my résumé was, of all companies, Microsoft.

It was 1998, soon after the formation of MacBU as an independent business group, and the new team was staffing up on Mac-focused developers. The existing roster included devs with a wide range of interesting experiences in the industry (one senior developer had previously worked at Apple on HyperCard’s file format, among other technologies.) The opportunity to work on a well-supported project with a group of really smart folks gathered from all over the world – as well as Excel architect Rick Powell’s persistence – eventually got me on board.

At this point I’ve been with MacBU for over eight years, starting as a developer in Mac Excel, where our first challenge was to move our development environment and code from MSVC to CodeWarrior so that we could move forward on the platform. I was the Excel dev lead through the Carbonization effort of Office v.X, rewriting the older and thicker layer of Excel’s event handling nervous system to be based on the native OS X (and more preemptive multithreading-friendly) APIs of Carbon. Since 2002 I’ve been focused on managing first the development team and now the Redmond engineering teams as a whole, which among other things means doing what I can to maintain an environment where smart people will continue to want to come and work.

I’ll have to save some stories for later posts, as this “brief” introductory post has already gone long, but I’ll close up with a short state of the union.

One nice thing about MacBU is that things are certainly never dull, working as we do at the intersection where Office as a powerful and constantly evolving standard for “information work” meets the rich and rapidly evolving platform of the Macintosh. This combination entails ongoing engineering challenges, which have proven particularly intense for the release we’re building now. We have major work underway for Intel-based hardware, significant rewrites of user interface code to run in composited HIViews, and a cross-platform push to provide completely revamped and more open file formats, as a sampling of “under the hood” changes alone.

The good news relative to all this is that, while it’s taken time to grow and sign up the caliber of people we require, the group of developers we have on board now is the largest we’ve had in MacBU’s history, with a lot of fantastic people on board. Our test team has geared up with the most robust arsenal in terms of test plans and automation we’ve ever put together as well, and is at work validating deep quality as major functionality gets checked in. That said, we’re still looking to grow further, and I’d be remiss if I failed to mention that we’ve recently created new openings in both dev and test here in Redmond (and also have openings on our engineering teams in Mountain View, all of which you can review and/or respond to here.)

So, folks are downright busy and we still have a ways to go before we can share a whole lot more about new features in Office. In the meantime, we’ll try to keep the blog posts coming. Again, welcome and thanks for tuning in.