Monthly Archives: August 2005

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

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. 

Punching up the abstract…

Despite my name making an appearance in the session title (it appears to be gone now), several people have observed that our current session abstract for our PDC05 talk is a bit, uh, bland, especially when compared to some of the other sessions. Here’s what we originally submitted:

Visual Basic is designed to be the most productive language for writing data-centric, solution-focused applications. Meet with the designers of VB and learn about upcoming language features that will improve developer productivity, including new features that enable optimized queries over objects, XML, and databases in a consistent way.

I proposed punching up the abstract in the hopes of making it a little more enticing, and it looks like that’s now live. Here’s the new abstract, which you can find in the session list:

Visual Basic 9.0 will offer radical improvements in its ability to work with data in all its forms: as objects, as XML, as relational data. Join the language architects for a detailed discussion of features such as query comprehensions, object initializers and anonymous types that enable querying data in a more flexible, natural way than ever before. Also, get a glimpse into the future of dynamic programming in VB with coverage of new features intended to radically simplify working with dynamically typed data on the .NET platform.

Hmmm… What are some of those things?


Happy blog-day to me…

As with last year, my recognition of my second anniversary of blogging is a bit belated. And, as with last year, it’s hard to believe where all the time has gone. The whole blogging phenomenon seems to have transitioned from adolescence to early adulthood and is rapidly growing up (as much as it ever can). Wonder what year three will bring?

Microsoft Cept

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…