I’ve been thinking about coining a new verb:

go steveb tr.v. To suddenly escalate an issue to the CEO/President/Senior VP of a company out of frustration when dealing with a low-level employee of a company. (steveb is the email address of Microsoft CEO Steve Ballmer.) As in, “Yeah, we were talking about the fact that we cut that new feature the customer wanted and I said there wasn’t anything I could do about it, so he went all steveb on me and emailed my VP.”

To go steveb is really kind of the Hail Mary pass of the corporate world: you’ve exhausted what you see as all reasonable options of dealing with the lower-level people in the corporation, so you’re giving up and hoping that by complaining to the top people that they’ll do something about your problem, even if just to shut you up. A bit of a desperation move because, of course, this will not particularly endear you to the people who you were previously dealing with (and who will likely be told to work on any response that you end up getting). Doesn’t work most of the time since high-level people are, by nature, practiced in the art of the polite kiss-off, but always worth a try.

I’ve certainly done this at times — when I had a disastrous experience traveling internationally with Expedia in the mid-90’s, I had to go steveb on them to get back the money we wasted on hours of transatlantic calls. Of course in that case I benefited from the fact that Expedia was part of Microsoft at the time… Now that I’ve reached a certain level of public note, I get to be on the other side of things, when people think “Enough of this flunky, I’m going to go straight to the top!” Since I’m always in pretty good alignment with my organization this has never been much of an issue for me to deal with, and on rare occasions its even got stuff moving that I was personally in favor of (but lacked the internal clout to move on my own).

Anyway, the verb is so MS specific that I doubt anyone will ever use it except me, I thought I’d share…

…I have to say I’m very heartened by Erik Ruker’s discussion of the features in the upcoming Access 12. My outside perception is that not a lot has been happening with Access in the past few releases (something that I’m sure is not totally true, but there you are), but it looks like they’re definitely getting a lot of traction in Access 12. Lots of interesting stuff coming up! I’m looking forward to the beta…

Something random the other day make me think of an old email I’ve kept stuck in the archive folder, and I thought people might find it amusing. Many years ago, a coworker sent around an entirely tongue-in-cheek email on “How to be a PM” in which he covered the many underhanded ways that a Program Manager could get a developer to do their bidding (not surprisingly, the author was a PM). So I crafted a response on how, as a developer, to deal with the underhanded tricks that PMs can play. Here it is for your enjoyment…

(Obligitory caveat: Remember, this is just a humor piece. No one I’ve ever known at Microsoft has ever done anything like this. It’s all entirely theoretical. Caveat emptor. Your mileage may vary. No warranties express or implied.)

How to be a PM (and how to deal with PMs)

1. Always ask for more than you want, a ratio of one bogus request for every 4 or 5 real requests is usually a good ratio. Too many bogus requests and you’ll be laughed at (even more than usual), too few and something you really want might get cut. Act depressed when the bogus feature is cut.

Dev response: Always overestimate the time it will take you to do a task by at least a factor of two or three. No task takes less than half a day, even if it will take you five minutes. If there’s something you really don’t want to do because it’s hard or you don’t like the PM, start your estimate at a week. If the PM argues with you, keep saying “Oh, I forgot about case x.” and add a week to your estimate. Repeat until the PM stops arguing.

Alternate Dev passive-agressive response: Do as many of the bogus requests as possible and tell as many people about them as possible. When people ask “who told you to do such a stupid thing?” indicate the PM. Soon everyone will be laughing about the PM behind their back.

2. Divide the feature as many different ways as you can to get the lowest possible dev estimate. For example, if a, b, c, d, and e are the parts of the feature be prepared with options like “What if we do a, c, and part of d?” Initially developers will put up defenses like “doing c requires that we do b.” Pause thoughtfully and give them another combination. If you’re determined eventually you will win.

Dev response: First, make sure that no combination of parts adds up to anything less than a week and a half. Figure out the one part of the feature that is absolutely critial (usually a), but smarter PMs will make it c) or d)) and estimate it at a week. As above, keep upping estimate until PM leaves.

3. Ask another developer. While it’s good to get a second opinion, feel free to go for a 3rd or a 4th. The more times you ask the better chance for that bold “I can do that in half a day” estimate. Sometimes called the Fru method [Ed note: named after a PM on the team at the time].

Dev response: None really necessary. If the PM comes back and says “y says it should only take half a day,” then just reply “fine, then y can do it.” Problem solved.

4. Many different ways exist to get tasks to developers, use them all. If you stick to one it’s too easy for them to develop a good defense. Add things to the spec, push something through [the design change process], enter a bug that doesn’t actually state the problem but exposes it in such a way that the developer will find it, have someone else enter the bug, ask a 3rd party to pretend they had the idea for the new feature (most effective when it comes from outside the company through a manager type but that’s harder to orchestrate), get another product to do the same feature (good trick within [the org I was in at the time]). In short, be creative as you make work for other people.

Dev response: As much as possible, don’t play their silly games. Your single most potent weapon (if you haven’t figured it out by now) is your estimation as to how much time it would take to do something. Most PMs have no clue how much time it takes to do anything, so you can say the most outlandish things and they will believe you. For example, PM: “Dev, I need to you change the menu item “Exit” to “Quit”.” Dev: “I’m sorry, but there’s a lot of code that depends on that, so it’ll take me at least a week to change it and it will probably completely destabilize the product.” PM: “Oh, I see. But y said that he could do it in five minutes.” Dev: “Well, then, have y do it.” OR Dev: “Unfortunatly, y doesn’t completely understand the complexities of our menu system, so his estimate is wrong.”

5. Only spec 75% of the feature. All developers will finish the last 25% of the feature even if they don’t have the time in the schedule.

Dev response: First of all, since usually PMs really don’t understand what they’re asking for anyway, always do exactly what is in the spec because nothing you do is going to be right anyway — at least this way you can say “but it’s in the spec!” and make the PM look like an idiot. If the spec is unclear, don’t ask the PM about it, just interpret it in a way that is the easiest for you, even if it makes no sense. If you don’t like part of the spec, ignore it and later say “I must have been working off an earlier version of the spec that didn’t have that feature in it.” If the PM challenges you about something they say was in the spec, imply that if they’d written the spec properly you would have understood what they wanted.

6. Drug your developers on candy and other treats.

Dev response: If a PM really wants a feature, say “I’ll do it if you give me a six-pack of beer.” If the PM readily agrees, ask for a case instead.

7. When describing new features, write up their descriptions as if other new features already exist. If the developer gets half way into feature A and realizes that they need feature B to complete it chances of accepting feature B go up.

Dev response: If you fall for this, you get what you deserve. 

Larry Osterman blogged yesterday about the funky name assigned to some new expansion pack that we’re shipping, which jogged my memory about a funny naming story that’s probably old enough to be repeatable. In fact, it’s been so long that the story may be incorrect or apocryphal, so take it all with a grain of salt…

Before I worked on Visual Basic, I spent most of my time working on Microsoft Access. In fact, I interned on Access about a year before it actually shipped its first version. The name of the project at the time was “Cirrus” and it had no official product name at that point. By the time I finished up my final year of college and made it back to the Access team, the product name had been chosen and we were just a few short months from shipping. One day I was chatting with one of the marketers on the team and he told me a story about how they’d come to the name “Access.” Apparently, they’d hired an outside research firm that specialized in product naming. They paid them some big chunk of change to go off and think about possible names for Access and then come back and give their recommendations. They came back with a set of ideas, but the one that always stuck out in his mind was “Microsoft Cept.” Yes, “Cept,” as in “con-cept” or “pre-cept” or “ex-cept.” They apparently had some wacky ideas about how Microsoft could run a whole marketing campaign around words that ended in “cept.” (Apparently ignoring the obvious homophone that immediately springs to mind, namely “septic.”)

Thankfully, the marketing department ignored the suggestion and took a look at the trademarks that Microsoft already owned. We’d apparently shipped a “Microsoft Access” product before – it was some kind of DOS dial up program that had died a quick death – and the name seemed to be perfect. And thus we have “Microsoft Access,” not “Microsoft Cept.”

Anyway, that’s how I remember the story. My apologies to those involved for any distortions that time has made to my memory…

OK, normally I try to be pretty even handed about the whole “VB vs. C#” thing since we’re all one big happy family, but sometimes I just gotta wonder… Scott Wiltamuth (he’s the product unit manager for C#) was talking on his blog about the recent Office System Developer Conference and said:

Given VBA’s long history with Office, one might expect VB .NET to be the primary language among .NET developers using Office as a platform.  But I’ve seen a lot of anecdotal evidence that C# usage of Visual Studio Tools for Office (aka VSTO) is high.  I’ll try to get some solid data on this and share it here.

Which raises the question: are C# programmers just masochists? I’ve always kind of suspected, what with the case sensitivity, the cryptic syntax, the lack of declarative event handling, and so on. But it seems to me that programming against Office is one of those places where VB has got it over C# hands-down. Sitting on my desk are some chapters of a book that I’m doing technical reviews for. The book is about using Office from managed code, and several of the chapters (maybe the whole book, I haven’t gotten that far) are written in C#. So as I’ve read through the chapters, I just keep circling things and writing in the margin things like “this limitation doesn’t appy to VB” and “this code is simpler in VB.”

For example, VB supports optional parameters, named parameters and passing expressions to reference parameters, whereas C# doesn’t. So when printing, code that in VB looks like:

Doc.PrintOut(Copies := 2, Collate := true)

Becomes in C#:

object copies = 2;
object collate = true;
Doc.PrintOut(ref missing, ref missing, ref missing, ref missing,
    ref missing, ref missing, ref missing, ref copies,
    ref missing, ref missing, ref missing, ref collate,
    ref missing, ref missing, ref missing, ref missing,
    ref missing, ref missing);

There are other various little gotchas sprinkled throughout Office (like the fact that C# can’t bind to Word’s Close event and VB can, although I think VSTO finesses this a bit), which raises the question: why would you use C# instead of VB to automate Office unless you were a bit of a masochist?

OK, OK, OK, I’ll admit it – I’m only half serious here. I don’t really think that C# programmers are masochists who whip themselves on the back every night chanting “I will initialize all of my variables, I will initialize all of my variables” and wear their “I Am Strongly Typed” hairshirts under their clothes during the day. In fact, I have it on good authority that many C# programmers are normal, well-adjusted members of society. But that doesn’t mean I can’t razz them a bit every once in a while…

Every corporate culture has it’s own set of acronyms, TLAs (three letter abbreviations) and jargon, and Microsoft is no different. I try not to let it slip too much into my blog entries, but a comment from M.J. Easton reminded me that a while back I did use one without explanation. In an entry talking about the DirectCast operator, I said:

In addition to the fact that we like VB, it’s also a great way to dogfood the product.

I don’t believe the verb “to dogfood” is unique to Microsoft at all, but it’s certainly an integral part of our culture. It’s short for “to eat one’s own dogfood,” which means “to use the product yourself that you are trying to sell to your customers.” The purpose of dogfooding is severalfold, but the main reasons are:

1) It proves to customers that we believe in the product.

2) Because dogfooding usually means using beta (or pre-beta) software, it helps flush more bugs out of the product.

3) It makes us suffer the same bugs and design flaws that we inflict on users, thus giving us incentive to fix them.

4) It’s a valuable reality check that the product is actually as good as we say it is.

5) Because Microsoft is such a large organization, it can flush out problems that could not otherwise be found prior to full-scale rollout at launch. (This holds especially true for corporate server products such as Exchange, SQL, IIS, etc.)

6) We learn how our products actually work, which is more often than not not exactly how we think they work.

All in all, dogfooding is a extremely valuable, if not sometimes painful, thing that we do at Microsoft.

(You can find a deeper discussion of the etymology of the word in the Wikipedia entry on it.)