Plan, Write Code, Test; Plan, Write Code, Test

Plan, Write Code, Test; Plan, Write Code, Test

As LeVine continues his explanation of the product cycle, he points out that the functions he's listed aren't really linear—one doesn't end before the next starts. They often occur simultaneously, with the intensity of the effort ebbing and flowing depending on the relationship of each to the launch date.

Inspired, he draws more lines showing how this works, pointing out that by the time of the Office 2003 launch, planning has already peaked for the next version of the product—Office 2006 or 2007 or whatever name Microsoft chooses. By now the diagram looks more like Figure 4-2.

Figure 4-2. Constant reinvention may be the best way to characterize how Microsoft revises its software products.

So, how would you plan for the writing of a book 100 feet high?

The process starts with a vision document, which basically lays out the objectives for the new product. It can be as short as a page or, as is the case with Office 2003, about 40–50 pages long. The vision document becomes the touchstone or reference point for all decisions made during the two-and-a-half-year journey down the developmental birth canal. It allows managers to keep a rein on programmers, whose natural penchant is to incessantly add clever little features and modifications to their work for the beauty of it—and end up totally missing the launch date. If a feature or proposed modification doesn't conform to the vision document, it gets scrapped or tabled until the next version.

After that, a more detailed roadmap is built—now we are into many, many pages of detail about the product—and later, a more detailed, piece-by-piece, feature-by-feature product specification. Angiulo points out that for Office 2003 there were thousands of detailed software specs produced.

"We do a lot of work inside here to manage how this team of more than 2,000 will be broken into smaller teams," adds LeVine. "We need to control the chaos, create groups that are small enough to have ownership of their part of the process and make the investments they need to do their job."

This is one of the reasons there are so many planners among the developers and testers on each development team—about one in five in the effort are planners. Do the math: If the actual number of people working on Office 2003 was, say, 2,400, and the average team size was 6 people, we're talking about coordinating the schedule and output of 400 teams. Quite the choreography!

From the roadmap comes the detailed plans—technical recipes, if you will—that the developers use as their blueprints for the code that will become the software program. Every few days, they produce enough software to be tested. It's the tests that determine how and whether all the different moving parts of the larger programs will work, and under which conditions they won't. Office 2003 will be a product with more moving parts than a Boeing 757, which is why at least half of the 2,000 people on the project are testers. In fact, hundreds of other developers at Microsoft have the task of developing the software that will be used to test the software and, yes, the software to write software that will test software.

Thus does Office 2003 gets shepherded along. Code, test, integrate, test, recode, adjust, test, finalize, test, get feedback, retest, and so on. Each day, programmers turn in completed code by 4:00 p.m., and overnight it is blended with the code from other teams into a skeleton version of the product, called a "build." This allows for testing the interplay between the software written by the different teams. When the skeleton is fully fleshed out, the product is done.