A software legend has somehow arisen that Microsoft waits
until the last release candidate and then tunes up performance at the very end
before the software goes out the door.
Nothing could be further from the truth; good performance needs to be
fundamentally designed and architected into the product--something far too risky
to do at the last minute. From Beta 1 onward, a large portion of the
resources of Office development are spent making sure that the software is
speedy enough: testing on memory-constrained computers, processor-constrained
computers, terminal services, Run From Network, x64, and all sorts of different
From the perspective of the Office 12 new user experience, performance is
critical. The very visual nature of the Ribbon, with lots of galleries and
Live Preview, lends itself to experimentation. A key goal of the Ribbon is
that it's easy to poke around to find and use new functionality. However,
most people will only poke around if the interface is responsive and crisp.
For example, if it took two seconds to switch between tabs, it might dissuade
you from browsing the Ribbon as readily. In fact, we've noticed a profound
link between performance and usability; some usability tasks that totally fail
when the interface is laggy and lethargic suddenly do great once the software is
With the huge number of improvements in Office 12, making sure the software
is responsive is a really critical task. But it's one that we're totally
committed to, because great performance is one of the fundamental building
blocks of great software experiences.