microsoft – gee bobg

Score one for the engineers

I’ve been asked about the reason for my low opinion of Microsoft. It isn’t just me of course — a lot of technologists regard Microsoft that way. Here’s an anecdote that illustrates why.

The year is 1993. No one’s ever heard of the World Wide Web. Few people have even heard of e-mail. Too often, when I explain my role at the e-mail software startup Z-Code to friends and relatives, I also have to explain what e-mail is in the first place.

Those who do know about e-mail in 1993, if transported to 2009, would not recognize what we call e-mail now. To them, e-mail looks like this:

It’s all plain, unadorned text rendered blockily on monochrome character terminals. For the most part, variable-width, anti-aliased fonts are years in the future. Boldface and italic text exist only in the imagination of the reader of a message that uses ad hoc markup like *this* and _this_. Forget about embedded graphics and advanced layout.

However, in 1993 something has just been invented that will catapult e-mail into the future: the MIME standard, which permits multimedia attachments, rich text markup, and plenty more. Almost no one has MIME-aware e-mail software yet. Meanwhile, at Z-Code, we’re busy adding MIME capabilities to our product, Z-Mail. The capabilities are primitive: for instance, if we detect that a message includes an image attachment, we’ll launch a separate image-viewing program so you can see the image. (Actually rendering the image inline comes much later for everyone.)

The Z-Mail user is able to choose an auto-display option for certain attachment types. If you have this option selected and receive a message with an image attachment, your image-viewing program pops up, displaying the attachment, as soon as you open the message. (Without the auto-display option set, you explicitly choose whether or not to launch the viewer each time you encounter an image attachment.)

There comes the time that the marketing guy at Z-Code asks if we can add automatic launching of Postscript attachments, too. In 1993, Postscript is the dominant format for exchanging printable documents. (Today it’s PDF.) Turns out that a lot of potential Z-Mail users are technically unsavvy business types who exchange Postscript files often, jumping through tedious hoops to attach them, detach them, and print them out. Automatically popping up a window that renders a Postscript attachment right on the screen would be pure magic to them, changing them from potential Z-Mail users into actual Z-Mail users.

But there is a problem. Postscript files differ from image, sound, and other document files in one important respect: whereas those latter types of file contain static, inert data, requiring special programs to render them, Postscript files are themselves full-fledged computer programs. The Postscript renderer is just a language interpreter — like a computer within the computer, running the program described by the Postscript document.

Virtually every Postscript program — that is, document — is completely innocuous: place such-and-such text on the page here, draw some lines there, shade this region, and so on. But it’s perfectly conceivable that a malicious Postscript document — that is, program — can act as a computer virus, or worm, causing the computer to access or alter files, or use the network or CPU in mischievous ways without the user’s knowledge or approval.

So launching the Postscript interpreter with an unknown document is risky at any time. Doing so automatically — as the default setting, no less, which is what the marketing guy wanted — is foolhardy. (The reason it’s generally safe to send Postscript documents to Postscript printers — which include their own Postscript interpreters — is that unlike computers, printers do not have access to resources, like your files, that can be seriously abused.)

We, the Z-Code engineers, explain the situation and the danger. The marketing guy dismisses the possibility of a Postscript-based attack as wildly unlikely. He’s right, but we point out that adding the feature he’s asking for would make such an attack more likely, as word spreads among the bad guys that Z-Mail (a relatively widely deployed e-mail system in its time and therefore a tempting hacking target) is auto-launching Postscript attachments. Marketing Guy argues that the upside of adding the feature is potentially enormous. We say that one spam campaign containing viral Postscript attachments could cripple the computers of Z-Mail users and only Z-Mail users, a potential PR catastrophe. Marketing Guy says that our users don’t know or care about that possibility and neither should we. We say it’s our job to protect our users from their own ignorance.

The issue gets bumped up to Dan, our president, who is clearly leaning toward the marketing guy’s enormous potential upside. But after we vigorously argue the technical drawbacks of the plan and our responsibility to keep our users safe in spite of themselves, he goes with the suggestions from Engineering: do add a Postscript-launching option but turn it off by default, and educate users about the danger when they go to turn it on.

This is a run-of-the-mill example of the kind of tension that exists between Marketing and Engineering in all software companies. Issues like this arose from time to time at Z-Code, and sometimes Engineering carried the day, and sometimes Marketing did. It was a good balance: it took Marketing’s outlandish promises to keep Engineering moving forward, and it took Engineering’s insight and pragmatism to keep the product safe and reliable.

As an industry insider, my impression of Microsoft is that Marketing wins all the arguments, with all that that implies for the safety and reliability of their software.

Sole survivor throws “Caution” to the wind

Monday, which was the 16th anniversary of the end of one adventure and the beginning of another, was also my last full day at Danger, and not coincidentally also the last day of Danger. Yesterday it was officially part of Microsoft, but I was not, so I showed up early to drop off my security badge and free SIM, collect some checks, and leave for good.

To my great surprise, I was the only Danger employee to decline an offer from Microsoft to remain with the company.

Why was I? Certainly a big part of it was my well-documented distaste for Microsoft, but I was by no means the only one at Danger to feel that way. The fact is that I was already growing disillusioned with Danger even before the Microsoft announcement.

In January of 2003, when I had been at Danger for barely two months, I was moved to send the following message to my new engineering colleagues:

From: bobg
Subject: A different perspective

At today’s engineering meeting, and afterward in various individual discussions, I heard a lot of griping about the ambitiousness of [an engineering] schedule. I’m here to tell you: it’s a lot better than the alternative.

Before I came to work here, I was at a different company that for purposes of this message I’ll call Caution, Inc., because in a lot of ways it was the opposite of Danger. The managers were in thrall to a dysfunctional version of the software engineering lifecycle. The simplest feature had to have a requirements document, needing several iterations of meetings until all “stakeholders” could sign off on it; followed by a specification document, likewise requiring meeting after meeting to polish it to a high gloss; to be followed only when the spec was finished by an architecture document and still more weeks of meetings and sign-offs; and then implementation, testing, and release plans, each of which sometimes spun off recursive instances of the entire lifecycle. Only much later did you actually begin writing code; and for scheduling purposes even simple projects were scoped in terms not of weeks or months but entire quarters.

I think the whole idea behind getting everyone to buy in at each stage of the project was to have your asses covered when you finally wrote something to spec and a stakeholder had an objection. But what value in being able to say “You should have thought of that sooner” if the company goes out of business long before anyone gets a chance to object?

Needless to say, nothing got done. Not one damn thing. When I started at Caution, the team I was on was nearing its first anniversary of working on a project that involved nothing more than writing a Unix command-line interface to a web-based bug-tracking tool. The interface comprised four commands, each of which parsed its arguments, invoked two or three API calls, and printed some output. But they hadn’t completely nailed down the exact right behavior, so they had barely begun to write any code at all. After a year.

By the time I left eight long months later, that project was still not complete. There were other projects that came up, naturally, and from time to time I would surreptitiously whip out a complete, working implementation of something in an afternoon just to show how it could be done, only to be chided for trying to do an end-run around the process.

Once in a while something really urgent would come up and then we’d kick into gear, throwing the process out the window and invariably producing a satisfactory solution in short order, but overall, Caution was the very embodiment of the saying, “perfect is the enemy of good enough.”

How to describe how badly that sucked? Visions of immensity come to mind — Mt. Everest, the Grand Canyon, the Great Plains, the night sky, the federal budget — but nothing seems quite adequate. I’m a crackerjack programmer; I need to be building software all the time, not refining the illustrations in a months-old design document. At Caution, everything was slow, soporific, comatose. That company was in Santa Clara, and as many of you know, I live in Mill Valley. Doing that commute every day and having only that stultifying grind to look forward to was a major drag.

It came as no surprise to me when Caution suddenly announced it was laying off half the company (including me, mercifully) — nor that after the layoff, the company was pretty much able to continue doing what it had been, simply by revving up the speed of the people it had left.

What I’m trying to get at is this: you’ll always succeed at only a fraction of what you try to do. It’s better to dangerously try a hundred things and succeed at 25% than it is to cautiously try ten things and succeed at 80%.

As a newcomer at Danger, obviously I missed all the angst surrounding the delays leading up to 1.0. But let me tell you what I see: a successful, energetic company with an awesome product, abundant talent, great press, and many opportunities. If overambitious targets and always-imminent ship dates are what’s needed to achieve those things, then bring ’em on.

Before Caution, I worked at other exciting startups, including two that I co-founded — one of which was the Internet Movie Database, which a lot of you will recognize as a cool company — and I can tell you without hesitation that this is the gig I’ve been most enthusiastic about. The energy level, the rate at which things happen, even the sense of impending crisis — they all mean high stakes, something worth spending my time on. The daily commute to Palo Alto, which is almost as long as my terrible old commute, now strangely seems to go by in a flash.

I like having too much to do and too little time to do it in; it’s far more interesting than the reverse. Obviously there’s a balance to strike between danger and caution in the schedule, and maybe we’ve erred on the side of danger in the past, but that’s the right direction in which to err. Danger’s got a good thing going on here. When we do get enough slack in the schedule for the engineers to go off and figure out how we’d like to redesign everything, that’s when I’ll start to worry about the future of the company.

At that time, my message was cheered by many. Over the years, though, despite my best efforts to prevent it, Danger did eventually, inexorably transform itself into “Caution, Inc.,” bit by imperceptible bit. For the past few months my work there has consisted of almost nothing else besides preparing, revising, and reviewing engineering-process documents — and futile back-channel attempts to get things turned around so we could do some real work.

Some of my colleagues will be surprised to hear this, but it was mid-January of this year when I finally decided to throw in the towel, fully a month before we found out about the merger. As the author of the “Danger/Caution” missive I could hardly stay much longer without betraying my integrity. I only stuck around as long as I did to see Danger through to the very end (and also to reap some monetary benefits relating to the merger).

The same week that I decided Danger’s transformation into Caution was irreversible, this confirmatory omen greeted my eyes as I showed up for work one morning:

The strangeness

Yesterday’s trip to our new corporate overlords (I mean protectors) was disproportionately strange to me, as the entire past two weeks have been, ever since I learned that Microsoft is acquiring my company, Danger.

What’s more natural in Silicon Valley than a rich but hidebound old company trying to stay ahead of the market by snapping up a successful, innovative startup? What could be less surprising? And yet there is a persistent sense of unreality for me that is itself taking me by surprise. When I first heard the news I was momentarily stunned, and then I recovered and said to myself, “OK, that’s that,” and expected to remain cool and unperturbed about it from then on. What other reaction even makes sense? But that’s not how it’s turning out. I’ve been in a kind of a daze. Why?

Obviously it’s due to the echoes, for me, of NCD’s acquisition of Z-Code in 1994 (which also happened mostly in February; which, come to think of it, was the same month that I first interviewed for the Z-Code job in 1992). I was a very early employee at Z-Code and along with the rest of the engineering staff expected that we were on a path to taking the company public. We had a successful product and some lucrative partnership deals, we’d won some industry awards, and we always got good press.

Now that I have a much better understanding of what’s involved in taking a company public, I can see how naïve it was to flatly insist that Z-Code turn down the NCD offer and continue trying to IPO. In 1994 the dot-com boom was still a few years away and Z-Code was having distinct growing pains; it was by no means certain we could remain a leader in the e-mail software market.

But at the time none of this was obvious to us. All we knew was that the upside of this deal was much, much smaller than what we’d been toiling for, and that NCD in particular was an odd choice of an acquisition partner. (They produced X terminal hardware; we produced an e-mail client to run on a huge variety of platforms.) The engineering staff was disappointed and bitter. We opened bottles of tequila and vodka the night we got the news that the deal had closed; it’s the drunkest I’ve ever been. Z-Code’s founder, Dan Heller, who sold out to NCD over our objections, became the focus of our resentment. It has taken me this long to be able to say: sorry, Dan.

It’s hard to overstate the intensity of my emotions when the NCD deal happened. I had committed myself body and soul to a vision that was being allowed to die. It was the biggest trauma I had ever suffered. I threw tantrums. For example, I just found this in my e-mail archive:

From: bobg
To: schaefer, lowery
Date: Wed, 9 Feb 1994 14:26:20 -0800

I am staging a work stoppage. I don’t know when I’ll be back. Bye.

In the end I grew a little more mature, professional, and jaded; the deal went through and the companies combined; and NCD managed Z-Code (and then itself) into the ground over the next few years. Our Z-Code equity translated into just enough NCD stock options to allow me and three co-workers to leave two years later (again, in February!) and bootstrap our own e-mail startup, which still exists today, so, not a bad outcome. But the psychic damage had been done, and my reaction today to being gobbled up by Microsoft is perhaps not so hard to understand.

Déjà Mountain View

In 1994, Network Computing Devices bought Z-Code, the startup where I had been working. The staff of Z-Code was bussed from our Novato office down to Mountain View for a come-to-Jesus meeting.

Later today, the staff of Danger will be bussed to Mountain View for a come-to-Jesus meeting with Microsoft.

The first time, there was drunken carousing by the vanquished on the bus, and a videocamera to capture every embarrassing moment. Today there is likely to be drinking and videocameras again but this time there’s also YouTube for broadcasting the embarrassing moments to a global audience.

“Danger”ous liaison

Hooray, Yahoo! Way to resist assimilation by the Borg:

Yahoo Formally Rejects Microsoft Offer
SUNNYVALE, Calif. (AP) — Yahoo Inc. has formally rejected Microsoft Corp.’s $44.6 billion takeover bid as inadequate.

Oops:

Microsoft to Buy Mobile Startup Danger
SEATTLE (AP) — Microsoft Corp. agreed Monday to buy cell phone software maker Danger Inc.

So it looks like I’m about to become part of Microsoft, the evil empire. For Danger it’s an outstanding deal. For me personally? Well, my opinions on Microsoft’s collective technical wherewithal are well-documented among over five years of bug-tracking and source-control comments that I’ve written, as Microsoft’s irksome coding practices impacted my work at Danger in one way or another (usually in the form of their producing e-mail messages that failed to obey accepted Internet standards, but that my code had to deal with correctly anyway). Excerpts of my comments follow; here’s where I get to channel famed Internet curmudgeon jwz.

Some mail agents, particularly those fine ones emanating from Redmond, break up long URLs in plain text message parts using line breaks.

In MSP-land, a message contains “a body” and then maybe some “attachments,” which doesn’t really map onto the Internet standards for mail, but you can insert your own snide comment about Microsoft’s attitude towards important and widely accepted standards.

There are 100’s of different computing platforms and 1000’s of possible e-mail clients. I happen to be using Evolution on Linux. But the IETF standards govern most of those variants. Outlook is a notable exception. Microsoft is notorious for ignoring rules that everyone else plays by.

When we told Microsoft that [a component of the Danger mail system] routinely downloads both the plain-text and the HTML versions of the body (for those messages that have both) in order to construct multipart/alternative MIME structures, they acted as if we’d told them we married our cousins.
They may come back and request that we only download one or the other to protect their servers, which are apparently of 1960’s vintage.

MSP returns lists of addresses (such as the “To” and “Cc” recipients of a message) as a semicolon-separated string. This does not comply with Internet standards and breaks the Javamail address parser, which [a component of the Danger mail system] uses when converting from MSP data to IMAP-appendable data. I am sure Microsoft had their own very good reasons for this; I do not begrudge them the choice to be idiots.

[A component of the Danger mail system] records the set of messages already fetched from an IMAP account using the messages’ IMAP UID’s. If the folder’s UIDVALIDITY value changes, we are supposed to discard all saved UID’s as invalid (per the IMAP standard). In theory this only happens when the folder has been destroyed and recreated with new contents, but in practice it’s more common that the IMAP server simply loses track of the old UIDVALIDITY (I’m looking at you, Bill Gates) and assigns a new one.

Add application/vnd.rmf as a synonym for audio/rmf. Good thing you got money, Mr. Gates, ’cause you ain’t got charm.

(Why couldn’t they just have used the standard designator “audio/rmf” like everyone else?)

As I suspected, it’s Microsoft’s fault. (*audience gasps*)
Outlook is using Unicode to encode the funky characters but not declaring it in the enclosing MIME syntax, which it’s supposed to.

The following refers to Microsoft’s practice of sometimes wrapping perfectly good message-attachment data in a strange construct called a TNEF object that only Microsoft programs can reliably decode.

Leave it to Microsoft to take data that is encapsulated in a format that was meticulously, ingeniously designed to be neutral with respect to transport, and enclose it in an opaque wrapper they call “transport-neutral encapsulation format.”

To understand this one, you have to know that:

In HTML, a “comment” (which is ignored for display purposes) begins with the string “<!–” and ends with “–>”;
The characters < and > are referred to by programmers as “angle brackets” and sometimes as “brokets“; and
There was a buggy version of Microsoft Outlook (or possibly Word) that produced HTML that began with a comment such as “<!– Created by Microsoft >” which, as you can see, did not properly terminate the comment, so it looked to other mail software like the entire HTML message body was a comment, and none of it got displayed.

Microsoft
Gets things wrong oft.
Ending an HTML comment with a bare broket?
That broke it.
– Ogden Bob

Now I face a decision: submit to the will of Landru, or make my escape before I become one of us one of us?

If I go by Kevin Spacey movie quotes — as good a guide to living as any, I suppose — I should stay:

If you’re not a rebel by the age of 20, you got no heart, but if you haven’t turned establishment by 30, you’ve got no brains.

(I’m well past 30, and Microsoft is nothing if not establishment. Maybe I can aim to reform it from within?)

On the other hand, if I go by the choice of song that, I swear, randomly came up first (odds against: 99.96%) as I got on the highway this morning to attend the Danger-Microsoft “Come to Jesus” meeting, my course is clear. It was, “Gotta Get Out” by The Bicycles.