040. Creating the First Real Office [Ch. VII]
“Code is like dinosaurs.” –Me in a memo trying to be a thought leader
Welcome to Chapter VII, 1995 to 1997 and Office 97. As PC sales surge, growing at a rate of 60 percent in 1996, the enormity of the internet becomes widely realized and will soon dwarf the impact of everything that came before it.
The Apps and the Office team were 110% focused on what should have been the last months of Office96 as part of our 12/24 plan of parallel releases. The product turned out to be much more difficult to finish and the new Office-centric organization met with much more resistance than planned. On top of that, Office 95 took our entire Test team to get out the door, putting us behind on quality. In other words, the 24-month project was going to take longer but we did not yet know how much longer.
Something about Windows 95 shipping changed Microsoft, especially at the top and how the company thought strategically. It was as though with the success of Windows 95 came the need, though not necessarily the ability, to think big thoughts and to develop big plans for the future. The products we were working on were a given, but just not interesting. Everything interesting was yet to begin.
Or was that really the case? A post about planning for a big future while trying to build a product that was already late.
Back to 039. Start Me Up
It was as though we had not been working on Office96 for the past year. With all the excitement of Windows 95 (oh, and Office 95) the conversation quickly turned to asking what would Office do next, after the release we hadn’t even finished and was late. It was kind of weird.
In a relatively short time many things changed. MikeMap retired and with that a slight change in the organization to accommodate, with BillG taking on product groups directly. Microsoft Research was a few years old and occupying more and more of BillG’s headspace. Windows NT 4.0 was on a path to completion and with that a solid spot in the minds of IT leaders, especially for the most anticipated business product of all, Microsoft Exchange email. The much-anticipated Cairo project began to fade in interest and what became more interesting (and ultimately much more important) would be bringing the Windows 95 user experience to the Windows NT operating system kernel. The browser war between Internet Explorer and Netscape and the broader competition over back-end server technologies for the Internet was well underway. Windows would kick off a series of updates to Windows 95 primarily for the benefit of holiday or back-to-school PC Sales (Windows 98, Windows 98 SE, and finally Windows Me). For Office, by many accounts it appeared as though Office had successfully taken the leadership position in the new product category of suites. We were still paranoid about competition especially that Lotus was now owned by IBM and had a huge sales motion behind it.
That seems like a lot of work going on and it was, but from a company strategy perspective it was as though that was all known and thus, for lack of a better word, boring. The real excitement and interesting work was answering the question from BillG “What is Next?”. There was an almost insatiable demand to know our plans for a few years from now, not our current development efforts. It was rather sudden, but soon the altitude of our company dialog was less about the products under development and more about what products should be under development. The concern or even fear was not losing in the next release cycle but in the ones that came later. Intellectually that seemed prudent, but practically it was enormously frustrating as I would alternate between significant execution challenges and vague discussions about an infeasible future.
There were people in parts of the company that had what were considered great visions for where to go, but it always seemed to me like there were practical ways to get to 90% in much less time. Others had ideas for how things should be done, but clearly there was no way to build those now because of some limitation like how different everything else would need to be to be able to build that. Innovations like work from General Magic captivated BillG and everyone but were not selling well (even with a big IPO). As I’d become accustom, a failure in the marketplace was not a failure for BillG so that meant we needed to treat it like a potential competitor. I needed to find a way to engage in this dialog and to represent applications and productivity effectively as “thought leadership” (a popular buzzword).
We were still deep in building Office96, the second part of the 12/24 strategy of working on a pair of releases in parallel. In fairness to me, this was occupying every cycle I had. We were almost two years into the project by the end of 1995 and it was clear we were going to ship much later than planned. Yet, no one really wanted to talk about Office96. Rather, everyone wanted to talk about what would be next. What would be big and bold. To us, Office96 was huge. The scale of the product was greater than anything we had ever done, greater than anything done in the industry.
Office96 did not have any of the a priori constraints of Office94, other than shipping as a suite all at the same time. At the start of any release in early 1994, product teams were thinking big. This time, in addition to each app, there was also the new OPU team (Office Product Unit) team thinking big. Aligning these big thoughts would be add to the challenges.
Our Desktop Applications process was a unique expression of a product development lifecycle. It was not the historic and inappropriately applied moniker of “waterfall”—a legacy process where first requirements are gathered then specifications written, and then code developed until testing signs off.1 It is also not what would be thought of as agile, in more current terms, when products are increasingly built up over time constrained by short cycles or sprints (primarily because we took a long time, though some also would say because we did not change the software in response to external inputs along the way as well). Throughout the development schedule the product was kept stable and usable by the team but not in a shippable state until defined milestones or beta tests.
The Apps/Office process of setting large aspirations that span 18 to 24 months and scaling implementation as the project evolved was unique at Microsoft and clearly the source of the stability of the products and the position in the market that continues to benefit the company today. Apple remains a lone exception and has brilliantly mastered a delicate balancing act of consistent yearly releases (unbelievably amazing) and long-term product plans patiently released over multiple years. Business is a social science and as such drawing causal relationships between processes used at different companies is risky thinking.
Whatever one might call this process (it just became known as the Office process), the assumption BillG had was that whatever we were able to articulate to him was already booked. On the one hand, this was great and it meant he could count on us to deliver. On the other hand, it was incredibly frustrating for him for two reasons. First, the ability to articulate a product extremely concretely—literally with early working code that he knew would ship, screen shots, and endless specifications—meant it was going to feel done and immune to his tweaks and inputs. Second, the very existence of a working and reliable product meant that it was time to move on. It was almost a curse of being perceived as reliable and focused on execution. Still, we were very late and didn’t even know how late we were.
BillG and NathanM leading Microsoft Research were focused on 5 years out or more. There was nothing special about that time, other than it was longer than anyone was already working. We used to joke that if from the very start a project took 3 years to complete then everything beyond that was infinity years away. A project that someone said would take 5 years would never finish. The world would be so different by then and the choices we would make so different why solidify plans now. That argument did not hold water at all. We had to do something to move this discussion forward. We started writing more and taking risks in talking about the future, a future we were not quite working on yet. It was uncomfortable.
First, we set out to cast Office96 in more futuristic language and goals. In other words, re-skin Office96 not as what we were doing but as what we could be doing next on top of it. We called this Project X. Nothing about Project X existed at all. It was simply a name and a memo to have a discussion. Design manager Brad Weed (BradWe) and the design team even mocked up the ideas in Project X and we demonstrated it at the Company Meeting and in a vision presentation at COMDEX in 1995. Brad began hiring designers from the new programs in interaction design popping up in Europe, particularly in UK and Netherlands, including from the Royal College of Art (where Apple’s Jony Ive has long been affiliated). To kick off the process I made my own demo—a single screen illustrating the concepts I thought we needed to show off. It is comical in the use of clipart and PowerPoint but it was a good conversation starter with design.
Project X took over the desktop with a series of new metaphors. There were filing cabinets that contained binders that could be constructed by searching across all your documents, not just physically storing them. Calendaring with a timeline view and task management would be easily accessible. It would be easy to have small notes (Post-It like) attached to any item in the system. People were the center of activities not just documents, with easy access to contact cards. A little teddy bear, a loveable precursor to a paperclip, was always there to help you as an intelligent agent. There were also virtual desktops so each project a person might be working on could have its own set of tools organized appropriately and quickly switch between them. All of these were rooted in Office96, but projecting out years if we had more operating system services and synergy.
Working from this sketch the designers (after deservedly mocking me) created an interaction sequence that was an ultra-modern skin, so to speak, on the features of Office96. The designers were the same ones designing the real menus and dialog boxes, so it made sense. And like that, everyone was far more excited in what was to come than in anything we were currently working on.
That might seem like a success, but in fact it quickly blew up and many across the company became either concerned or needed to know more so they could adjust their plans to fit in with Project X. In some parts of the company this would be viewed as huge win. For Office this was a problem. We not only had to finish Office96, but we were a big business and the last thing we needed to do was to need to explain to customers that the Office 95 they were thinking of buying would be obsoleted by the new cool Project X. So, I quickly wrote a memo explaining Project X. While I spent most of the memo explaining the features shown at the Company Meeting and how they related to the real work of Office96, I also used it as a chance to try to align the work of Windows (still called “Systems” by many) and Apps.
Although this sounds totally drastic, this memo will make it clear that we were really building Project X all along, though we lacked a shared vision of how it all fits together. In this memo we will detail the various technologies and architectural components that make up Project X, who is responsible for the design, and who is tasked with building them.
While a lot of people were excited by Project X, they were less excited by the prospect of trying to align all of our products again after Windows 95 given all the work already going on. In particular, I was learning that the job of aligning fell to Office to align with Windows, not the other way around. Office needed to do a better job of using the new underlying technologies in Windows to build applications. Except there weren’t any new underlying technologies. What BillG wanted to do strategically was repeat the GUI Windows-Excel innovation cycle, but what was the next GUI, the next app?
So back to writing. Realizing that the problem seemed to be not as much a lack of big thoughts, but a lack of ideas for evolving the whole of the platform, meaning Windows and Office. In my memo “On the Evolution Of Office” the key thing I put out there was that while we just finished 12/24 of two releases in parallel, then why not “12/24/48” and start working on something four years from now! I wrote that while Office96 was slipping and the team was reeling from the trauma of trying to do two releases in parallel. We weren’t being political as much as just trying to put forth some framework for talking about the future that was infinity years away. NathanM loved it!
By betting all or a portion of a team on building 48 month developments into the current product, we are doomed to failure. No group is smart enough about our industry to know what bets to make now in our products today in order to have them pay off in four years, all in the same product. One way to think about this is to ask what features were worried about four years ago in Excel and compare that to what ended up in the product. Although there are some things that have been perennially on the list of adds, and then cuts, the marketplace clearly did not miss them (though perhaps we regret not having done them for development efficiency reasons). We can continue to explore how to just “extend” our 24 month cycle to a 48 month analogue, but it would be hard to convince me that we would find a process by which we can work on meaningful features in parallel with our current products.
What is needed, though, is a redefinition of the 48 month aspect. Instead of thinking of it in parallel to our current process, we should consider the 48 month time frame to be an independent bet on something that we think (strongly believe) will pay off handsomely in the four year time frame. In other words, while we should continue to bet largely on the code, process, and architectural aspects of 12-24, we must look hard at the current state of the marketplace and products and spend some of our efforts on a completely different effort. As PeteH likes to remind us, we must be sure that the “generals are not fighting the last war.”
What was most important to me was helping not just BillG and NathanM but the rest of our team to see that we were not crazy. So to do that we took a concrete technology approach to describe all the places in the applications that we made assumptions about how PCs worked and why those needed to change. The reason assumptions needed to change was because Moore’s Law was firing on all cylinders across CPU, RAM, disk space, along with Metcalfe’s Law on connected networks becoming increasingly powerful clearly describing the growing internet. Designing our software for an old world was just dumb. I really like the idea of documenting the context and assumptions of a product to force a rethinking of what still makes sense, or not.
The analogy I used was that “code is like a dinosaur” implying that the comet that hit our codebase was the Internet. The assumptions baked into Word, Excel, and PowerPoint make for a long list of potential points of competitive weakness (disruption was not yet a word in business vocabulary, but that would fit). These assumptions included:
Stand-alone applications dominate
Categories consisting of spreadsheet, word processor, presentation graphics, database
Testing software was an afterthought, or a small portion of development at best
Teams were started with 2-3 programmers, but we reached a limit at about 40
The product architecture was really the work of “one guy”
Sharing code is hard
Disk-based file formats
Networking limited to file/print sharing
CPU bound applications are the norm
Virtual memory not available
Operating system services are slow
Users can run setup on their own
Documents are primarily printed
Images in documents are primarily adornments
Macros were run in process and for a single application
Most information is stored locally
Document structure manipulated and created by the user
The dialog now shifted. These were topics we could discuss across teams and meetings. In a parallel list, the memo offered some ideas for new assumptions we could make about building productivity software. I realized that Project X had not done enough to incorporate the Internet and so we focused much more on how that changes everything:
Drawing and graphics are the norm, not an exception
Virtual memory replaces disk-based file formats
Multi-stream documents are the norm, along with progressive rendering
Interoperating with Internet protocols is a requirement
Programmability should start from higher abstractions than the user-interface
Documents will be viewed on-line
Documents will contain more active, user-encoded behavior
Applications need to be easier to setup and install
Knowing the structure of a document is of paramount importance
File formats need to be tagged for upward compatibility
A few more months would pass and the Internet would be more solidly represented in our products. In fact, we were well into building and innovating in Internet Explorer, Internet Information Server (Microsoft’s web server), Internet capabilities across the Office applications, and more new products than we could name. This led to a final manifestation of these ideas with a decidedly web-centric view. So a final memo before we got around to actually shipping Office96, was “Web-Centric Productivity”.
In this memo we articulated many ways that we could build applications to take advantage of the web, across storage and management of documents, personalization, collaboration and annotations, solving our setup and deployment problems, and more. We did yet another prototype called Project Stretch to visualize these ideas. As mentioned many times before, I had a disdain for code names, so this is a tongue-in-cheek reference to a famous IBM project that was not commercially successful but led to many core technologies for later mainframes.
The click-through prototype of Project Stretch. It is fascinating to consider this in the context of today’s Internet. At the time we made this, a browser could render just a few dozen text formatting tags and images, with most user interface being done as big click buttons. Scripting was new to browsers by just a few months. ActiveX was the big bet the browser was making, but this was something that raised concerns given the Apps experience with the underlying OLE technology.
Stretch envisioned an Office available all the time, from any device, running in an industry standard browser. It was mid-1996 while Internet Explorer 3.0 was being developed, and as such it predates technologies that became essential for creating richer, desktop-like, user experiences (even scripting was only months old, technologies like DHTML were years away). HTML as it currently stood had only the most minimal text rendering capabilities, which we found troubling in Office though we were determined to adopt it. The most interesting strategic bet being made (in Internet Explorer 3.0) was what became ActiveX, which was rooted in OLE and thus something that concerned me while also saluting the strategic flag. The prototype became a way to articulate what would eventually lead to products such as SharePoint and OneNote, as well as underlying technologies for sharing and collaboration.
With this executive level, long-lead effort going on in the background, the real work of building Office was taking place. Each and every day was a new challenge in the face of ever-increasing scale. What was once three independent application teams in Word, Excel, and PowerPoint, along with a new product for email and a new team called Office building shared code, had to grown to be a single, well-functioning product team. Still, we were not yet where we needed to be.
Office was late. The team was not gelling. It was painful.
On to 041. Scaling the Office Infrastructure and Platform
Most attribute the definition of the waterfall development approach to the classic article by Winston Royce Managing the Development of Large Software Systems (PDF), Proceedings of IEEE WESCON, 26 (August, 1970) . A careful reading of the article shows that Royce was critical of this and the Apps approach was much more like what he prescribed. Alas, the rise of agile and in particular internet time 1996-2000 all but eliminated the idea of holistic product planning and replaced it with shipping and iterating on feedback. This would be an ongoing skirmish between some groups in the company but would become a major challenge for me in about 10 years when I moved to Windows. More on that to come.
BillG thought it was his job to challenge every team to be more forward thinking at all times. On one hand, that is a core part of Microsoft’s success. On the other hand, he never really understood the tension between forward thinking and the focus required to finish software because he had an attitude that once an idea was conceived and agreed to, the software was done. Except the software wasn’t remotely close to being done.
At this point Office 96 was on the cusp (well, really on the upward slope of the cusp, maybe even before the inflection point of the cusp) of being the project that did more to work in parallel on long-lead forward thinking features and architectural renewal (both themes BillG would always push) than any project in the entire history of Microsoft. But, since it was conceived and agreed to before Office 95 shipped, in his mind it was done and the two years required to finish was just wasted time where we weren’t being forward thinking enough. I am being a little over-dramatic. He of course did understand intellectually, but he also hated it.
NathanM joined the fray to try to get all of us to be better at thinking ahead and championed the 48 in 12/24/48. I had a long meeting with him where I was able to relate the huge amount of work to finish that was being glossed over in these discussions. He also gave me the insight into the need to not just refine old value incrementally but to always make sure there was large, unique, new value in a release. Finding the right ideas that translated into large, unique, new value was also a lot of work, but uncertain and lossy; things that did not fit into an engineering process where one of the primary goals was successfully shipping. Big ideas that never ship produce zero value, but incremental progress has its limit in exciting users to upgrade. Navigating this tension would drive tweaks to the engineering system in the future. Later we would see that the Office engineering system could ship far more new value than end users could ever understand or adopt.
So fun to revisit the schematic of Project X you put together. And to see the reference to the term "Concept Car" in the slides.
Pragmatic development teams in Office were skeptical of the 'vaporware' the design team had stitched together in Macromedia Director. But because it had been shown at the company meeting and at Comdex - something new for a design team at Microsoft - the Office teams knew Project X couldn't be ignored. That added to the tension Jon DeVaan mentions here.
I remember Steven saying to me, "What takes a Designer a few weeks to do in Director will take years to build." And it's true. So Steven did a masterful job of 'dumbing down' Project X into ClipArt so that the most salient and achievable ideas could be properly partition, refined, designed, and costed.
That's where the idea for 'Concept Car' came from. The auto industry had long made a practice of introducing advanced styling and engineering in their 'concept cars' that they then would syphon off into production vehicles. They still do. It was a metaphor every developer could wrap their head around and made doing vision prototypes in the future much more collaborative across disciplines.