"Our challenge is how to rebuild this jumbo airplane while flying."
That's how Igor Zaika, a Microsoft Distinguished Engineer working on Microsoft Office, recently described the conundrum facing Microsoft's Office team. How does a company continue to support and avoid disrupting its 1 billion Office users while rebuilding Office's core infrastructure to make the suite run on operating systems beyond Windows?
Office currently consists of tens of millions of lines of code that the company built starting 30 years ago. Office got its start as a bunch of individual apps written in C; Microsoft bundled them together in 1990, even though there was very little shared code between them, Zaika said. At that point, the team thought it would be a good idea to rewrite the suite to create a common code base for Office for Windows and Office for Mac, which Microsoft launched separately in 1985.
"Shockingly," Zaika joked, "it did not work."
While the team salvaged some of the shared Windows-Mac Office code, Mac users were unhappy with Office apps that didn't look or work like other Mac apps.
The Office team took on the rearchitecting challenge starting a couple of years ago, with the understanding that sharing code is good, but sharing too much code is not, Zaika told the audience.
This time around, the Office team is designing mini platform abstraction layers (PALs) and trying to make smart choices about how and how much UX code to share across the different operating systems which it is working to support.
While some inside the company thought Microsoft should fork its Office code base and create different branches with diffferent teams dedicated to supporting each operating system, that's not the current approach Office is taking, Zaika explained. Microsoft did do this back in 1997 when it separated the Windows and Mac Office codebases, but that's not it's doing now, he acknowledged. The Office team also has opted not to go the "least common denominator" route with Office. Users want to take advantage of the newest platform-specific features on each operating system to the greatest extent possible.
The Office team is doing all its work in place. It is building well-defined, composable components, using mechanical refactoring where possible, and unit tests where not. The focus is on keeping everything working at all times, on all platforms, Zaika said. The team has zero tolerance for automation regressions on any platform, and is dogfooding its code bases internally at large scale across platform.
"If you do it right, having a legacy code base turns out to be an advantage because it forces you to do 'the right thing,'" Zaika said.
The goal is to maintain a shared core of intellectual property — the guts of Office — all written in C++ and keep that shared core as large as possible. By doing this, risks of document corruption are reduced. On top of that core, there is a set of native UX appliction programming interfaces. The UI pieces of each version of Office aren't written in HTML5, Zaika said, and there are no intermediate layers or custom frameworks involved. The team also is building multiple PALs, not just one fat abstraction layer or different emulation layers.
The goal of "write once, run anywhere" which technologies like Java, Flash and HTML5 were designed to try to solve by pushing the level of abstraction as low as possible or making application programming interfaces (APIs) very broad sounded good, Zaika said, but ended up creating impedance mismatch. Compatibility and interoperability problems, among others, arose.
"Either you blew up, or the OS (operating system) blew up," Zaika said.
Instead, with mini-PALs, which the Office team builds in place, the company can match performance and semantic expectations of its specific applications to the OSes supported. Microsoft expects these PALs to evolve as platforms add new functionality, he said. Instead of trying to build for the specific performance, thread and other constraints that are unique to each operating system, the idea was to create APIs to match all the platforms. That's why and how Microsoft built the cross-platform AirSpace architecture as part of its new Office design, he said.
With a common C++ core, a thin native UX layer and evolving PALs, Microsoft is building its Office apps so they work on different OSes with fairly little tweaking required. Zaika cited PowerPoint as an example, noting that only four percent of its tens of millions of lines are unique to the WinRT/Universal version of Office (the touch-first Office release some of us have been calling "Gemini"). If the XAML code is excluded, the amount of shared code is 98.6 percent he said. The PowerPoint for Android code base includes 95 percent shared code, Zaika said.