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.