037. Capone and Email Without Typos
“What could be more magical than all of a sudden my email didn’t have typos and it was easy to add bullets?” –EdF, Word Development Manager
All we wanted to do was bring the rich formatting and lack of typos people experienced with Word to email. We saw how email was replacing many uses for Word and figured it seemed like a good idea to reuse all that code to make for better email. That put Office right in the mix with every other division—each of which had their own idea for how email should be done. While the WWW and browsers were killer applications for consuming all that was out there, email was the killer application for communicating with friends and family, and increasingly coworkers. So every team had to do something.
Some reading this today will point out Zawinski’s law, “Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can.”1 That is precisely what was going on at the time, except a few years before this too-truthful observation. Email was the first time I experienced a classic Microsoft dynamic, which is when something is interesting every group finds a way to build their interpretation of it.
Back to 036. Fancy Wizard and Red Squiggles
Leading up to Windows 95 shipping was probably the most explosive era in product development in Microsoft history. Whole new divisions, lines of business, and products were springing up so fast it was often difficult to keep track. It wasn’t just the strategic clarity of focusing on Windows, but also expanding Windows into new areas from automobiles to televisions, from markets as far flung as hospitals to passenger aircraft, not to mention the global expansion of the ever-expanding enterprise sales force.
It wasn’t just that every one of these new efforts was capitalizing on the Windows strategy that was finally approaching market readiness. It was also, and perhaps more important, that each effort also lead the way in embracing the Internet.
While most everyone outside of Microsoft would aim their concerns at the “The Internet” icon on the Windows 95 desktop, the ownership and strategy behind that was all contained within one team in one division, Windows. The real battle, or more appropriately consternation and endless debate, would take place over a much less discussed desktop icon, “Inbox”—the email client application that could connect to Microsoft’s two email products, the legacy MS Mail and the not-quite-finished enterprise mail product, Exchange, as well as what was then called internet mail (email that used standard internet protocols such as POP3 or IMAP).
Unlike a WWW browser, building the company’s email strategy lacked a singular organizational focus. Rather, it was more of a classic strategy of permissiveness and letting many flowers bloom, an approach that Microsoft would employ repeatedly (photos, messaging, collaboration, and more). When something was cool or the next big thing, it always seemed as though every group would somehow manage to find the resources to squeeze it into their strategy. Eventually, in the 1990s every part of the company had an email strategy: Windows, Online/Consumer, Servers, and Applications. Those didn’t always align or even work well together.
Windows, like OS/2 and Unix and soon Macintosh, was like every operating system and assumed that connecting to standard internet protocols for email was important. Even though by email accounts, most consumers were reading email in America Online (AOL) or one of the other online services, these protocols were wildly popular with Internet Service Providers (those providing dial up access directly to the internet without the walled garden services of an online company) and small businesses. About a year after Windows 95 shipped, the team released “Microsoft Internet Mail and News” (codename Athena) which would go on to become one of several extremely popular email clients for customers using internet protocols.
The Online/Consumer division was building the Microsoft Network which of course had email. The email experience relied on a purpose-built mail server, custom protocol, and mail interface that would power the @msn.com email addresses. In a short time, the same group would acquire HotMail, which provided free email directly through any WWW browser with an internet connection. The team would spend quite some time reconciling the implementation of this strategy.
Servers, the division building the back office products powering the client/server strategy for business, was the home of the team building EMS as previously discussed. The team was primarily made up of hardcore server or backend developers focused on scale, reliability, and performance. EMS had many more email features than could be supported through internet protocols, such as calendaring, shared mail folders, and enterprise-level security. To support those EMS had its own proprietary protocol or API, which meant it needed to build its own email client. So they did.
Applications, specifically the Office team, ended up part of this effort by a re-organization in mid-1994. There was a second email client effort going on codenamed Ren & Stimpy (mail and scheduling) to be a full replacement for MS Mail and Schedule+. Since these were mostly distributed as part of the Office product, it seemed to make sense that the team should move to Applications. This was an early version 1.0 product and far from shipping. The EMS team grew increasingly frustrated with the product compared to their own Capone effort. Ren seemed to tax the EMS server significantly more than Capone.
From an industry perspective, Microsoft’s largest competitor in email appeared to be Lotus Notes, which was gaining traction and with the recent 4.0 release showed a revamped user experience and focus on email and strong connections to the internet. I attended the yearly conference in Orlando and left suitably concerned. Ultimately, IBM acquired Lotus just a few weeks before the Windows 95 launch, cementing Notes as the premier competitor to both Office and Windows. The New York Times front page covered the deal along with several adjacent stories about the magnitude of this acquisition, financially and strategically.
Notes created the workgroup or groupware category, something Microsoft could not seem to get right. A variant of Windows, Windows for Workgroups, added some networking features but offered little competitively. Office had several packages done as add-ons to Excel to enable workgroup activities such as budgeting, but those too missed the mark. Visual Basic was being used to create collaborative applications and was going to be a key part of the EMS strategy, but that was far off and not the focus of the Languages team. The addition of Inbox to Windows 95 would be yet another attempt at turning up the competitive heat against Lotus with something neither core to a product team nor complete in execution.
What Lotus had done with Notes was create a product that was not squarely aimed at any existing Microsoft product. In fact, it landed between all of the groups. That meant on some days any group could simply ignore Notes and on others it could claim it was aiming straight for it in a competitive sense. Ultimately no one was accountable, and everyone could point to someone else.
In many companies, people look to executive management to clarify overlapping or incoherent strategies, especially in technology companies where we love to have all the pieces fit together well. In times of rapid change and high uncertainty, however, most leaders seek to maintain optionality and prefer the costs of internal organizational scuffles to the potential cost of having the wrong solution. This was decidedly BillG’s approach, which for all the bravado of review meetings he avoided at all costs making a binary choice between two groups and preferred to leave the differences to some natural course. It was as if he had hoped a Notes competitor would magically appear from within a group already tasked with competing with an entirely different company or product.
This drove me (and many) crazy, but as I reflect on this in hindsight it is only hindsight or told-you-so recollections that allow people to say they knew we should have done something different. No one knew how email would turn out, we just knew we wanted to be a big player.
Office had yet another view on email. It wasn’t as much an interest in building an email client as it was that email seemed to be positioned to replace the core use of our product, which was creating documents, spreadsheets, and presentations. In 1994, email was in the early days of making its way through the corporate world. When email was in use, as it was at Microsoft, it was clear that the role of the traditional 10- to 20-page business memo was declining. Our instrumented version of Word confirmed a gradual decline in short documents once email was in use. What used to be done as short memos printed and circulated in interoffice mail was being replaced by email.
At first this was somewhat terrifying for the most used anchor of the suite, but additional research showed that Word was still used for the most important and valuable documents, and often longer documents, created by multiple authors. In the pre-internet era this was some comfort for the team. The question remained, though, what, if anything, should be done about short documents? How could Office participate in email without being yet another group developing an email client application? We were just getting our minds wrapped around Ren & Stimpy, but that did not yet have a schedule and seemed more like a far-off project.
The Capone client was basic and while it was primarily (some would say exclusively) about EMS, it was also being pushed to be a stellar example of a Chicago application. By stellar, it meant that the user interface for mail needed to look like the Chicago file explorer and reuse as much of that code as possible, something Lotus or other competitors would never bother with. While there was little top-down direction over reducing the proliferation of email clients and servers, there was an intense focus on Capone being a great Windows 95 application.
This design, appearing to users like the file explorer, had been a key goal of BillG’s for years and was at the heart of his mission for a universal shell as sought after in the Cairo project. I was never a fan of building shells—they aren’t that important and frankly people make too big a deal out of them, but I was in the minority and much of Microsoft embraced the idea of building a killer shell. The shell was “just a place people have to go to in order to launch Excel and Word,” something ChrisP always said. (I would later experience firsthand the high levels of emotion people attached to launching programs when introducing Windows 8.)
Capone was far behind the proposed Chicago ship dates of early 1995, primarily because the mail server product was as well, though Capone could theoretically connect to other mail servers, which would justify inclusion with Chicago. In Chicago, Capone was named Inbox and received an icon on the desktop (that was really difficult to delete) representing the importance of mail for Chicago. Capone had a relatively simple text editor for creating mail messages, supporting only the basics of typing and formatting.
The Word team, especially Peter Pathe (PPathe) and Ed Fries (EdF), were fascinated with the idea of replacing the email editor with Word. PPathe (or his nickname Blue, which was also an email alias) originally joined Microsoft to lead what became the efforts around typography and printing. A veteran of the Boston tech scene (and both Caltech and MIT), Blue was a rarity in that he had experienced all of the ups and downs of the PC industry outside of Microsoft while at the same time came to the company with deep domain expertise, having worked on innovative PC software before Microsoft.
EdF was carved out of the same mold as ChrisP and JonDe, and often the three of them were thought of in the same breath. EdF joined Microsoft in the mid-1980s from the New Mexico Institute of Mining and Technology and was already an Apps veteran who had famously created fish-themed software including co-authoring a famous screen saver. He was leading the Word development team, which was the largest Apps team, and had successfully led the team through the groundbreaking Word 6.0 release. Ed would later go on to become a pioneer in Xbox and a legend in the gaming industry.
EdF routinely described his goals for Word and mail as, “What could be more magical than, all of a sudden, my email didn’t have typos and it was easy to add bullets?” Routine today, back then it was magical—and costly.
Mike Angiulo (MikeAng) was a new hire in OFFPM, assigned to design this feature and to make it work. That put him at the center of storm between Workgroup Applications (where EMS was managed, WGA), Chicago, Word, and the Office test team measuring performance. WordMail, as it was called, was the ability to use Microsoft Word as the editor for email messages. It ultimately became a grand slam of cross-group coordination, but also finger-pointing along the way.
Over several months, there were more complexities than one could count. The API to reuse Word’s editor was known as DocObject and was part of broad plans to enable Office apps to be used in WWW browsers (if a link opened a Word document, then Word could open up inside the browser like if it was an HTML page). This approach was countered by the Netscape plug-in API, announced after weeks of negotiations over whether Netscape would freely license our API for use in their Navigator WWW browser. This was my one experience with Netscape that would play a tiny (and mostly irrelevant though memorable) part of the future antitrust trial. (In 1998, the Department of Justice (DOJ) and twenty State Attorneys General would sue Microsoft, resulting in a long-running regulatory dispute discussed in a future section.) DocObject itself was based on the enormously complex OLE interfaces, which JonDe and team tried to make perform in 4MB of memory after the decision was made to stick with OLE when I was working for BillG.
The Capone client was not ready for primetime, and the interfaces and capability to extend it were no more ready than the rest of the product, including EMS. The challenge was identifying where the problem rested. The Capone team had been benchmarking performance with EMS, measuring both memory used on Chicago and a somewhat mysterious item known as an RPC. An RPC, remote procedure call, was a request to the Exchange server to do something—retrieve a message, sort an inbox, or lookup an address. Using Capone generated RPCs, and every RPC was one too many as the server was trying to scale to hundreds of users. In other words, the best way to scale the server was to avoid calling on it to do work, at least that is how it seemed.
During the project there was a puzzling discontinuity between the development team and the executives who expressed increasing frustration over the tension between Office and WGA. Executives, it turned out, were insulated from the product performance challenges because their mail was hosted (dogfooded) on a special dedicated server named OXYGEN, that had far more capacity per user than the typical employee experienced. Execs were also running some pretty beefy hardware and did not routinely experience the memory pressure that most would on 8MB PCs. This special executive treatment gave the false impression of progress when we were, in fact, struggling.
Capone had gotten the number of RPCs to an acceptable level, and it didn’t hurt that Capone was also on the same team as Exchange. When WordMail, coming from a different organization, was integrated into Capone the number of RPCs went up, mail messages got bigger (because they had nice formatting not plain text), and a lot more memory was used (because Word was running). The number of RPCs went up, and it was all WordMail and was unacceptable to EMS. MikeAng along with the dev and test teams spent months tracking down and removing what they could, and justifying what remained, to deliver Word as a mail editor.
The result was an insanely cool demo. Mail messages looked like fancy printed documents—so that one-page meeting agenda looked, once again, like what used to arrive by interoffice mail. The feature was too early for Exchange and too soon for 4MB or 8MB Chicago machines. The groundwork proved incredibly useful for Microsoft’s next email product in Office96, as Capone led a short life. There was great vindication of this strategy by the end of 1995 when widely read and highly respected analyst Bill Gurley wrote about the arrival of rich email with color, graphics, and even letterhead. We were just early with a crazy implementation.
Coming into the summer of Windows 95, we had little to show to compete with Lotus Notes. The Inbox, with WordMail, would have little to do with the competitive battle for the backend of a modern enterprise. The parallel releases of Office94 and Office96 gave us a second chance for Office to compete with Ren & Stimpy, as we will see. The pain this optionality foisted on the product, marketing, and sales teams and even customers might eventually pay off. That is why when I reflect on all the craziness of the strategy, it is difficult to say it would have been easier—yes it could have been easier. but if only we knew the future.
On to 038. Designed for Windows 95
https://en.wikipedia.org/wiki/Jamie_Zawinski#Notable_Quotes
The DocObject interface was a classic code re-use idea. Going way back, DDE pioneered cross application communication and that code was reused to add all of the interfaces to do document embedding, in-situ editing and OLE2. Then all of the OLE2 code was reused to create DocObject, where the entire host app canvas was used by the embedded app. It opened up a lot of interesting integration scenarios, the two mentioned by Steven (WordMail and Web of hyperlinked Office documents), and a third, Steven's absolute FAVORITE, the Office Binder.
One of my favorite software-biz insults was referring to Windows for Workgroups as 'Windows for Warehouses'.