Mystic Microsoft, Chapter Eight: A Mile In Their Shoes

Prologue | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | Epilogue | Afterword

May Thy love shine forever
On the sanctuary of my devotion,
And may I be able to awaken Thy love
In all hearts.
—Paramhansa Yogananda

"Vee play HAAAARDBALL hier!"

During our first meeting to discuss joining his team, my would-be manager, Friedrich, was explaining in his characteristic German accent how Microsoft's Developer Relations Group generally did business. DRG didn't like to take no for an answer: its Technical Evangelists, as they were called, were out to spread the Gospel of Windows—even if it required certain forms of, shall we say, intimidation. To make his point symbolically clear, Friedrich held aloft the 40-ounce Louisville Slugger that he subsequently gave to me.

I wasn't quite sure how I would apply this approach to my particular role. Coercion just isn't part of my nature. If I was to succeed in my new position with DRG (where, ironically, I now had the title of "software design engineer"), I'd need to learn how to win others to our systems without bullying them. My goal was to make Microsoft's newest technologies easier for programmers to understand and implement: I simply couldn't do that by force!

On a brisk Monday morning, the 28th of October, 1991, I came in bright and early to my new office in Building 9 at Microsoft's corporate campus in Redmond, Washington. Fifteen months earlier, with a heavy heart, my belongings had been moved away to Developer Support, located in nearby Bellevue. Now, with a heart renewed and uplifted, my belongings had been moved back.

Or so I thought. On the Monday morning after a move, you normally expected to have certain things in your office like your packing boxes and, you know, furniture. Mine was devoid of all solid matter save the secretarial return of a desk standing on end. The walls were bare. The phone jacks were dead. A few loose network cables dangled from the ceiling. And my boxes? They were still six miles and eight floors away, waiting patiently in the downtown Bellevue high-rise that had been my home the previous Friday.

Bellevue Place in Bellevue, Washington. Microsoft's Developer Support Group occupied parts of the building on the right; I was on the 12th floor.

It was not the most auspicious way to begin a new job! But DRG's exceptionally capable administrative assistant managed by day's end to procure a full desk, a working phone, a white-board, an old-tech terminal through which I could check my email, and a guarantee that my boxes and computers would show up the next day. By Wednesday I was running full steam ahead.

The Developer Relations Group originally formed in the late 1980s after the first version of the highly-touted OS/2 operating system turned out to be a market flop. Not that it wasn't a good system in and of itself: at the time it was clearly technologically superior to MS-DOS and Windows in just about every way imaginable, including its big selling point, "pre-emptive multitasking."[*] Still, it didn't sell.

Various folks in Microsoft's Systems Division got together to find out why. Technological superiority, they discovered, appealed only to the thousand or so die-hard geeks who bought the system on that principle alone. Everyone else, on the other hand, didn't even pretend to understand this pre-emptive multitasking thing let alone why they should shell out their hard-earned greenbacks for it. All they wanted were innovative OS/2 applications that took special advantage of the operating system to help them get their work done better and faster.

From this perspective it was easy to see the failure: the few dedicated OS/2 programs that were on the market, like one recipe-management database system, were about as interesting as oatmeal. Better software was available for even long-obsolete versions of MS-DOS. So if the new operating system was to ever get out of the kitchen, so to speak, Microsoft had to get Independent Software Vendors (ISVs)[†] excited enough to create truly innovative applications for it.

Thus was born the Gospel of OS/2, which went something like this: "The new technologies in OS/2 are way cool. If you, our wonderful, friendly ISVs take full advantage of these technologies, then your products will be way cool. Customers will love them. They'll clamor for them. You will sell more products. You will make more money. This is goodness." And from Microsoft's standpoint, of course, sales of the requisite operating system would naturally follow, thus naturally increasing the value of everyone's stock options. This, also, was serious goodness.

To disseminate the Gospel far and wide, Microsoft gathered together a handful of choice zealots—including Bob Taniguchi—and formed the Developer Relations Group. "And YEAH," sayeth the chronicles, "each bearing thus the distinctive and holy mark of Technical Evangelist, the chosen few WERE sent forth to spreadeth the Good News to all who wouldeth listen. And YEAH, if they DIDETH not listen, or they dideth AND yet faileth to surrender their hearts to the Gospel…then playeth hardball, did they, the few…."

Well, many ISVs did listen and a good number took action. Month after month, the Gospel of OS/2 steadily gained new converts. Then came The Great Schism (see Chapter Five, page 54): IBM took control of OS/2 and left DRG with little more than disillusionment. But it didn't last for long: just as Windows NT arose Phoenix-like from the ashes of Microsoft's OS/2 efforts, so did the Gospel. All it needed was a little revision. Overnight, the Gospel of OS/2 became the Gospel of Windows.

Now until this time Windows wasn't much to shout about. Each of its first three incarnations offered little more to ISVs than basic services; only the largest companies—the ones with lots of excess R&D capital—could offer truly innovative features to customers. Smaller companies, unable to develop such enhancements themselves, could compete only with each other for the market leftovers.

Windows NT and Windows 3.1, however, were changing the story dramatically. These systems offered such a powerful collection of new built-in technologies that small ISVs suddenly found themselves on a level playing field with the big guys. In fact, they had the advantage. It was no longer a matter of who had the most money but of who could respond most quickly—something at which smaller companies normally excel—with applications that took advantage of those technologies. And those who did would ride the great wave of prosperity.

By this virtue alone, ISVs were eager—even impatient!—to hear the transfigured Gospel. They flocked to DRG's developer conferences. They devoured DRG's white papers and press releases. They begged and pleaded DRG to bestow a blessed visitation on their corporate headquarters, even offering to pay everyone's expenses if needs be! Nobody, it seemed, wanted to miss out.

With demand rising exponentially, many more Technical Evangelists were needed. Every other week a new zealot was hired, indoctrinated, and sent out to preach The Word. In less than a year the ranks of the DRG apostolate had swollen from an elect few to a vibrant thirty-five.

In the process, of course, people—imperfect as they are—made their mistakes. Patience and sensitivity seldom flower in the garden of religious fervor; the weeds of boisterous dogmatism choke out the more unassuming buds of honesty and sincerity. Truth is easily forgotten in the desire to gain new converts as quickly as possible.

In the case of Developer Relations, the not-so-subtle distinction between sharing and imposition was easily lost on those Evangelists whom Bob colorfully described as "technical arm-twisters." In their fervid crusading to please He-Whose-Power-It-Is-To-Grant-Stock-Options, they forgot that marketing is a function of friendship, not force, and one that invites rather than commands. Blinded by passion, they played hardball to a fault, resorting, on occasion, to such questionable tactics that they succeeded in creating only alienation and distrust. And the trend was only getting worse.

This was the Developer Relations Group into which I came. DRG wanted to re-establish and strengthen its rapport with outside developers and for this it needed a fresh infusion of genuine compassion. Bob sought me out because he knew that my time in Developer Support had taught me both selfless service and habitual sincerity. I just couldn't allow myself to put anything above a programmer's individual needs, be it personal desire, group pressure, or even Microsoft's bottom line. Indeed, in Developer Support I had often given special knowledge to some of Microsoft's fiercest competitors that our own development teams didn't have simply because they'd never asked for it! And by doing so I gained the appreciation and trust of at least a few individuals in those other companies. Now in Developer Relations I would do the same thing on a much larger and much more visible scale.

My first assignment in this new role set a good precedent. Windows 3.1 had new "localization" features that were intended to greatly simplify the process of adapting software to overseas markets. Three weeks before I'd transferred to DRG, Friedrich had asked me to investigate whether they truly were simple and to understand how ISVs could use them most effectively. He gave me a good incentive, too: at the end of my very first week with the group I was to fly to Scottsdale, Arizona, with a few of our evangelists where we'dbeen invited to give presentations on Windows 3.1 to Symantec Corporation's annual engineering retreat.

Technically speaking I was fully prepared to give my half-hour presentation on the details of localization. But that was the only way I was prepared! When my turn came, I found myself staring out into a vast, dimly lit sea of two hundred eager and information-hungry nerds. Four hundred eyes (eight hundred if you count the glasses) were fixed on me, and four hundred ears on the knowledge I was expected to impart.

I was suddenly more nervous than I knew possible. Had I been able to flee, I most certainly would have. But with nowhere to run I chose the only logical alternative besides sudden cardiac arrest: get the talk over with as quickly as possible! From the moment I opened my mouth I was pegged on fast-forward. And after completely running myself out of breath several times—blah-blah-blah-blah-blah…*gasp* I-N-H-A-L-E! blah-blah-blah-blah…—I suddenly realized that my half-hour talk had taken all of twelve minutes. Obviously I wasn't a natural at this sort of thing.

Stage fright notwithstanding, I was at least sincere. I had no interest in preaching some sermon with the thought "this is the truth and you must accept it." Instead, I completely focused on the needs of my audience, explaining (rather quickly!) which localization features could be wholly ignored under a variety of conditions and offering ideas for using certain features in somewhat unorthodox, albeit helpful ways.

That evening, as we schmoozed with Symantec's developers in our hotel's outdoor hot-tubs, a number of them expressed appreciation (as well as amusement) for my effort. They were convinced that I had their best interests in mind and wasn't simply some glazed-over Microsoft poster-boy. They felt as though I had stepped into their shoes and understood their particular reality.

On my return to Microsoft it occurred to me that this kind of empathy might be the most effective approach to my work. Service is rooted in sincerity and sincerity is rooted in the love of truth. To see truth one must step outside the delusive limitations of any one perspective and relate meaningfully to other points of view.

As if in direct response to these thoughts, my next assignment afforded the opportunity to deeply explore this idea: not only did I get to step into the shoes of other programmers, I got to walk a mile in them! Indeed, the journey that began here covered many miles, as this one task became the cornerstone of my remaining career at Microsoft.

I was given the task of understanding and explaining a new technology called Object Linking & Embedding, or "OLE" for short.[‡] OLE was an outgrowth of the user interface metaphor known as the "clipboard" and a cross-program communication mechanism called Dynamic Data Exchange (DDE). Both had been around since Windows version 1.0 to allow applications to share information with each other, such as text and graphics. By adhering to certain standards and protocols any program could exchange data with any other, provided they both understood the data formats and protocols in question.

In the late 1980s there was a proliferation of new data formats as audio, true-color graphics, and video all came of age. What's more, the need to integrate different applications for the creation of rich "compound documents" with such elements was very much on the rise. Yet it was increasingly costly and difficult to update programs to understand every new custom design for achieving these ends. Programmers themselves were getting more and more fed up with the whole mess.

Microsoft and a number of key ISVs banded together to create a somewhat revolutionary solution: all new data formats would be wrapped inside a standardized abstraction. Internally, these "objects," as they were called, would contain both specialized data (image bits, color tables, video frames, etc.) and the necessary "intelligence" (program code) to manipulate that data and present it to the end-user. Programmatically, however, these objects would all interact through a standardized interface. This meant that any program capable of hosting the abstract "object" could incorporate all kinds of new data formats it otherwise knew nothing about, as well as those that had yet to be invented. Likewise, any program that provided such objects could be used with all present and future hosting programs. Such was OLE.

I'm giving you a simplified picture, of course. The OLE standard was making it possible to do extraordinary things and, as a result, it was extraordinarily complex for that era. Many intricate operations were required to create or manipulate an object. The protocol was also fragile: any mistake along the way meant complete failure. In effect, OLE was a new language that programs and programmers would have to learn to speak perfectly lest the whole thing collapse.

Offhand this didn't bode well for the technology's success. The work required to make a program OLE-compatible was as much, if not more, than making a program understand a veritable pantheon of different data formats. Fortunately, a good number of "sentences" in this new language were so common that they begged for standardization themselves. That is, many series of common tasks could be implemented as shared code libraries that the operating system would make available to all applications. This, in and of itself, would relieve around 80% of the burden.

As the operating systems vendor, Microsoft formed a small development team to deliver the goods. A high-level software architect designed the final technology and refined its protocols; two software engineers created the libraries; two technical writers documented everything; and one other engineer both tested the libraries and assembled a few sample programs. That was it.

Developer Relations was then asked, as usual, to spread the technology among ISVs, and spread it they did. By the time I joined DRG, our evangelists included something about OLE in nearly every presentation. Advance copies of the OLE team's work were flying out the door. And having given it such importance, ISVs were heeding our message and jumping on board, hoping with an almost blind faith that OLE would lead them to glory and riches.

Unfortunately, the Book of OLE in the Gospel of Windows wasn't very well developed; few of our evangelists really understood it. Although they preached the "good news" everywhere they went, they failed to point out that the technology was not universally applicable—its particular focus made it wholly inappropriate for many types of programs. To make matters worse, most ISVs couldn't make enough sense out of the thing to see this for themselves: the specifications, they said, were cryptic; the documentation unreadable. Before long, ISVs complained about the time they were wasting with this infant technology. Moreover, they were starting to distrust DRG for their misleading messages. Not good. Not good at all!

In the latter part of November 1991, Friedrich asked me to tackle the problem. There were obvious barriers to the widespread acceptance of OLE: could I find and eradicate them? Unaware of what I was getting into and where it would lead, I gladly accepted the challenge.

With my empathetic approach in mind, I decided to effectively become an ISV and undergo their plight for myself. With nothing more than the materials they had received from us I sat down to incorporate OLE into a few of my own programs. Mentally I isolated myself from the rest of Microsoft: I vowed to struggle with questions to the best of my ability before calling on the OLE team for answers. I was even physically isolated at the time—for one thing, my office was temporarily separate from the rest of DRG (they were in Building 5). And thanks to the never-ending Microsoft Shuffle I was, for six weeks, one of about eight people left in all of Building 9.

This was an excellent thing, as it turned out, because once I started to feel frustrated and confused I often announced my feelings quite vocally!

It wasn't that the shared code libraries weren't good—they were wonderfully fulfilling their purpose and the OLE team was apparently doing a fabulous job of getting them written, tested, and documented. However, it turned out that the whole project was far more complicated than the team had imagined. Under intense time pressure the technical writers could describe only what the libraries did but not why, when, and how to use them. The test engineer, under similar pressure himself, was pretty much forced to turn his sample programs—which would normally answer such questions—into complicated test suites for the sake of getting the libraries debugged.

This left each individual ISV with some astoundingly difficult and practically insoluble problems. Facing this for myself in virtual isolation I understood not only why ISVs were feeling upset with Microsoft but truly felt their pain. In fact, I literally became angry at the company—as if I were an outsider—for heaping such an unthinkable burden on me! Had you walked by my office at the time you might have been, shall we say, blessed with one of my many colorful litanies and rather irreverent invocations of, shall we say, a certain Jewish chap who taught among the hills of Galilee about twenty-one centuries ago. Everything was so confusing that I felt as though I'd been pounding my head into a brick wall until my upper skull developed a rather sporting plateau.

The whole time, however, a part of me stood back and observed. I had deliberately chosen this path out of love and compassion. My desire to help other programmers wasn't just a job: it was a mission. I willingly chose to take great pains upon myself to free hundreds, perhaps thousands of others, of the agony I was experiencing. In a sense, I was acting out in my own insignificant way—though it may be equally irreverent to say so—the Passion of that same Jewish fellow that I'd been invoking so often in vain. And in this general thought I found the necessary inspiration to keep me going through the greatest of trials.

Then something shifted. Something within me stirred…something that went beyond mere compassion. As I finally began to break through the barriers—that is, when I finally got my own damn programs to work!—I was experiencing more than just relief. I found myself experiencing…joy.

Yes, joy. Perhaps you don't think that getting a program to work could be all that joyful. But it is to a programmer. Really. You see, many of us types got started by writing useless little programs that did something "really cool" like bouncing a ball around the screen. For us, watching a bunch of symbolic source code generate something tangible was utterly magical and utterly joyful. Then we went to college, became professionals, and suddenly had to do "real work," earnest and demanding. No more horsing around: we were being paid for it now and had to take our work seriously. And if that meant toil and tears, as I had so often witnessed in others and as I had just experienced in the midst of OLE myself, so be it.

But now, after much pain and anguish, I had emerged on the other side of this "serious" business. Again, I wasn't just feeling relief, as is so often the case when a burden is finally lifted. No, I realized that I was once again feeling that joy of bygone days. I was actually having fun. Real, honest-to-God fun!

Pausing to reflect upon this deeply refreshing experience, I realized that professional software engineers were, for the most part, usually under such immediate deadlines and other pressures that "fun" just wasn't in the equation. Somehow in the process of earning a living we'dforgotten the magnetic joy that had first attracted us to programming, the "magic of coding" as I call it.

In that moment, my deep desire to help other programmers took a new form. I didn't just want to help them get things done: I wanted to help them enjoy it. I didn't simply want to relieve their pain: I wanted to inspire them. And I didn't want to merely educate them: I wanted to awaken them to new possibilities and potentials.

Yes, that was it! I felt joy and I wanted to share it! And by sharing it, I wanted more than anything to awaken that joy in others. This, I realized, was my real mission at Microsoft, even, in a sense, my personal ministry. My position within Developer Relations, my responsibilities, the very technologies I worked with—everything!—these were vehicles not for The Gospel of Windows, but for sharing joy. After all, joy is what we are all really seeking in every activity. To lovingly share one's inner light and awaken joy in the hearts of others is perhaps our highest outward responsibility as human beings.

Deeply inspired by this newfound purpose—though at the time I still didn't think of it in such overtly spiritual terms—I immediately began to apply it to my work with OLE. I wrote, for instance, a pair of "recipe" books that walked programmers through a step-by-step process of incorporating the technology into a program. But no dry technical manuals were these. Although I made sure they were both accurate and complete, I also tried to make them interesting, fun, and even humorous on occasion. And I must have succeeded—people repeatedly told me that they were "a real pleasure" to read. The sparkle in their eyes told me that I had touched them in a meaningful way, even if they didn't say so directly.[§]

My sample programs too, proved equally touching. People told me that they read more like documentation than code (which easily becomes gibberish even to programmers). Not only did they consider them the most useful samples they had ever seen, but also felt a satisfying sense of discovery as they worked through them and understood the technology more and more deeply.

How can I express my inner gratification? I delighted not in the personal praise, or even in the work I'd done, but rather in seeing people enjoying their experience with OLE. Truly, it was more than I had ever hoped for.

Indeed, as time went on an even deeper effect of this work began to reveal itself. You see, as this content made its way into the hands of many ISVs, I quickly became, to the public eye, the recognized "OLE expert." As such I was invited to give detailed presentations at some of the most widely attended conferences in the software industry.

After these lectures people usually plied me with questions and asked for advice on incorporating OLE into their projects. In the process of answering, I was pleasantly surprised to find myself not just thinking up a number of creative ideas on the spot but also encouraging each person to see a higher potential in both their work and themselves. In effect, I had somehow managed—almost without effort—to turn a potentially gruesome chore into a kind of exciting adventure in software engineering—"software" both for the computer and for the human being!

As I saw this sense of adventure come alive in people's faces, I realized that although many of my creative ideas would not prove the least bit feasible, it really didn't matter. I knew that people's kindled enthusiasms would eventually help them find their own paths, and their own answers. And I knew that this, more than anything, perhaps, would create a vibrant and dynamic software market in which Microsoft's own products would flourish.

I didn't have to preach.

    I didn't have to proselytize.

        All I had to do was share my joy,

            and people would convert themselves.


On my first trip to Scottsdale, Arizona, I took a day to drive north to the Grand Canyon and back (560 miles). I thought this sign in Flagstaff was rather fitting for OLE evangelism.

[*] A system feature that allows multiple programs to apparently run simultaneously, even if they were written to run exclusively.   [Return to text]

[†] A term used to refer to any software company outside Microsoft.   [Return to text]

[‡] Pronounced "oh-LAY," as in the Spanish olé (sans matador).   [Return to text]

[§] An Acquisitions Editor for Microsoft Press liked them well enough that he asked if he might just slap covers on them and sell them retail. Although they didn't quite have the necessary quality for such treatment, they later appeared as part of the OLE Programmer's Reference from Microsoft Press.   [Return to text]

Prologue | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | Epilogue | Afterword

Printed copies available from LuLu in Print | eBook, or Amazon in Print | eBook.

Please inquire about signed copies for $20 each (shipping included).

Interviews: Pathways (radio) | Present! (TV)

(cc)2016 Some Rights Reserved

Creative Commons License