Continuous Stability in Microsoft Office

Written July 26, 2021. Reposted April 1, 2026.

Microsoft Office is known outside of Microsoft as brand name for a suite of business applications including Outlook, Word, and Excel. Inside the company, “Office” is an engineering system with shared tools, libraries, services, and standards for producing world-class business services and apps with a common look, shared functionality, and powerful integration. In my time in Office from 1997 and 2012, I brought continuous stability to the Office engineering system. It was novel in this time and place, anticipating several business needs and industry trends. I made the work described here happen by my own coding, through my engineering team, or in direct partnership.

When I joined the Office Shared team, which maintains the Office engineering system, it supported about a thousand developers in a 2—3 year waterfall model. The product cycles were typically broken into three milestones that consisted of planning, coding and testing. The third milestone ended with “code complete”, after which the features would be fully stabilized, validated against a large release matrix, including DVD images that would get pressed and released around the world. Back then, getting from code complete to release-to-manufacturing (RTM) took almost another year, time which could have been better spent developing the next set of features.

Why did it take so long to stabilize and release Office? The waterfall model, much maligned in modern agile sentiment, was not itself to blame. Rather it was the huge process and technology gap between feature development and the final customer experience. This gap prevented the rapid feedback loops necessary for continuous integration and continuous deployment (CICD). The core of my innovation was eliminating these gaps. Once these gaps were eliminated, Office developers could be held to thorough testing of their work and enable CICD. Before that, it was guesswork. Over many years, I systematically worked through the entire Office engineering system to make previously arcane and complex processes accessible. Once I completed this work, any line of Office code could be locally built into any Office deliverable, which could then be installed and validated. This was my vision. More than a vision, this was my mission.

This vision was novel for the time, for Microsoft, and for the scale of our product. The Agile Manifesto, published during this work in 2001, offered the principle to “deliver working software frequently” aspiring to release every couple of months. We referred to this effort as “continuous stability” with the goal of a build every day and ensuring the stability of every one of them. Many colleagues thought this wasn’t possible for a product as large and complex as Office. Windows, SQL Server, Visual Studio, and the other larger products were not there yet. We set the standard for large products within Microsoft.

I identified this need during my very first role at the company. I could only write half of my feature --- code in Word, Excel , and the other Office applications--- with requests for new files, registry keys, or other configuration thrown to another team to implement downstream of the core Office builds. This took time and the changes often implemented incorrectly. This made features with such dependencies difficult to implement and impossible to stabilize in a timely manner. As we finished up that version of Office, I dove into the problem of installing Office and found a rats’ nest of incoherent code written in layers of different languages with no real architecture. I proceeded to invent a setup definition language (SDL), compiler and associated tools. This work allowed Office developers for the very first time to authoritatively define files, registry, web and other configuration associated with their features. Members of my team evolved these concepts into Windows Installer XML (WiX), which later became Microsoft’s first open-source project.

Achieving continuous stability required so much more. The scale of these products required improved management of built and non-built files, so I invented the equivalent of NuGet packages before Microsoft’s developer tools division did (“imports” from the “store” depot). I created custom build stages to provide authentic installation of client and server applications and services in the development pipeline (“devclient” and “devserver”). I optimized its installation on developer machines (“devinstall”) and worked deeply with our automation team to optimize its use on external test machines (“big button”).

As we finished each product cycle, we needed to produce final versions of its substantial release matrix. During my tenure, this consisted of about 50 products ranging from Office Professional to Word Standalone, each localized in about 50 languages, totaling 2500 releases. Each of these contained thousands of files to be managed, including the applications themselves, Office Shared code for stuff like UI and string management, hundreds of other libraries, plus dozens of utility applications such as language preferences and optical character recognition. I built mechanisms for managing this complexity and worked with our build team to distribute the release generation over many servers.

I spent a great deal of time with our build and localization teams to port the localization processes into these mechanisms (“intl” projects). We added a language construct to our source code so that developers could add “ja-jp” versions of their strings and products. As a side project, we partnered on “pseudo-localization” to simulate several character sets in one place, test excessive word lengths, right-to-left, and other language requirements. The Ireland team managing the localization process was initially reluctant to lose their specialized role in the Office organization but the partnership left them in a much stronger role as part of our ongoing “follow the sun” build operations which had them manage the official builds while the US team slept.

Office continued to grow with acquisitions like Visio and new applications like OneNote. Over time, we added services, including SharePoint, licensing services, Watson crash reporting, and Office web applications. My work kept pace, ensuring these new products landed with continuous stability end-to-end.

Even after years of work, there remained one essential part of Office not onboard to this vision: the Office Sustaining team. This team fulfilled several critical business roles. They directly fielded requests from our biggest customers, like the Department of Defense, who required specific “hotfixes” before rolling out (and paying for) new versions of Office. Microsoft’s Security Response Center (MSRC) would identify security vulnerabilities in Office, which the Sustaining team released as “public updates” to all users through Microsoft Update. The Sustaining team also produced “service packs” that roll-up hotfixes and public updates along with high-priority features. Each of these had swarms of program managers working with customers and tracking fixes through several different processes. The Sustaining team worked with the very developers and products I had been serving all these years, but with completely different processes and tooling.

Once focused on their work, I reengineered their core patch technology, speeding their work from days of slow and complicated processes down to seconds by building against the standards I had developed. But this work was difficult to integrate into their business operations. They did not have the luxury of years of isolated feature development and stabilization but had to keep releasing patches every month alongside any major process changes, including the ones I was proposing. The Office Sustaining team were providing Office-as-a-Service before anybody called it that. This team had engineering challenges beyond “changing the wings on an airplane in flight”. They had to deal with multiple generations of engineering systems that they had no control over. The very work I had done over those prior years made this team’s life more difficult.

I soon realized I could not crack this problem from the outside and decided to join the Sustaining team. Several colleagues warned against it, dismissing it as not a place for career growth (see IMWright’s take on sustaining). But I had my mission. I insisted on bringing continuous stability to the whole engineering system and this promised to be the hardest, most critical part of that. I felt partly responsible for the problems I unwittingly imposed upon them. I later realized that the Sustaining team had two advantages that I could bring to the rest of Office: they were close to customers and they released monthly.

I took to understanding our sustaining workflow and found that our technology for continuous stability improved sustaining productivity across the board. For public updates and hotfixes, Office developers were able to iterate quickly with MSRC and customers to validate the fixes before the Sustaining team was ever involved. The build system had features for parking changes (DPKs) to align with sustaining schedules. Our volume of fixes grew dramatically during this time (5x jump in MSRC cases in 2006 alone) and we were able to absorb that growth without issue.

A year after RTM, these ensuing fixes would be accumulated into “Service Pack 1” along with high-priority features not suitable for the other methods. Our ability to ship these packages improved so dramatically that we heeded customer calls for “cumulative updates”, serving as lightweight service packs. We started applying these sustaining methods to our beta release for early feedback. Through these innovations, the Office organization became dramatically more agile and responsive to customer need.

With our new, more capable engineering system, we fully organized the Sustaining team around monthly releases, regardless of the content. The business embraced that and started releasing new features this way. With the addition of “Click-to-Run”, a new deployment technology, the Office products fully became Office-as-a-Service. You can read about that transition from my VP’s perspective in his blog, Taking Office Agile.

My mission to bring continuous stability to the Office engineering system started from my own pain points and ended by enabling massive changes in the business. This work was principled and ahead of its time. I invented new technology for handling the scale of Office. I helped individuals and teams do their jobs better, making some roles go away and empowering others. This is my legacy.