developing mature software
There are many models of software development, the two best-known being the waterfall method and the spiral model. The models of software development that I studied during my computer science degree don't really capture how software development actually works. One of the main downfalls is that they don't capture the nature of a mature software project. Working on a project that has a seemingly endless scope like Office does has been an educational experience for me. One of the lessons that I've been seeing more and more every day is that the team is never working on just one version of the software. As a mature software project, the team is working on at least three different versions of the software: the version currently available today, the version we're about to ship, and the version after that.
Most of the Office team is, predictably enough, working on Office 2008. The dev, test, and program management teams are all working with a ruthless focus on finding and squashing those last-minute bugs that inevitably crop up. While their focus is ruthless, it's not absolute. They're also putting in a bit of time fixing some issues in Office 2004 (as evinced by this week's update). As we come closer and closer to RTM [1], the code for Office 12 gets more and more locked down. If there's a chance of a bug fix causing a problem elsewhere, then the fix is a candidate for going into a future service pack. This way, we get more time to ensure that the fix addresses the problem it's supposed to address without breaking something elsewhere.
Some of the Office team has started working on the next version of Office. I'm one of those people, charting out the territory and reporting back to the team with recommendations for the course we should make. How can we better meet our users' needs? The intrepid early explorers are trying to answer that question.
The next learning experience for me is going to come as I watch the team make the transition from working on Office 2008 to working on the next version. I've got a general idea of what happens next. The program managers start thinking about some specific things. The dev and test teams start doing some work under the covers to get the groundwork laid to really begin coding in earnest on the next version. On what day will I really feel like the team has made the transition from Office 2008 to the next version? Will I never be able to point to a single day because it is such a gradual process, or will it feel like the bit flipped on one particular day?
[1] RTM = release to manufacturing. Some companies call it GM (Golden Master). This is the date where the final bits are handed off to the folks that make the physical media that you buy. The next important date after RTM is GA (General Availablity), which is the date that you can walk into your friendly local Apple Store and buy the media. It takes a few weeks to create the media, which is why there's a delta between RTM and GA.
Comments
Anonymous
November 10, 2007
Hi, You said : "How can we better meet our users' needs? " when working on the next release of office for mac. But how can you do that if Office for Mac 2008 is not yet released ? and users have not yet used it...Anonymous
November 10, 2007
It's about focus. When you work on a project of the scope of Office 2008, you can't be everything to everyone. So you choose to focus on a particular group of users, study them in-depth, and meet their needs. For the version after Office 2008, we changed our user focus. One of my jobs right now is determining the defining characteristics of the users that we're focusing on. And in doing so, we're determining how we can better meet their needs. Some of their needs are needs that I think will be met with Office 2008. But not all of them are. So we've got some more work to do.