How Microsoft employees argue

Rabidly. And if they can't win, they get personal.


I work at a small software development company. We had four developers, including Pete, who used Microsoft products exclusively (wouldn't even consider anything else), was a "guru"-level design architect, and team lead on one of the two main products.

Pete took a job with Microsoft. As part of his going-away duties, he transferred the design of a new in-house utility to me. This utility (hereinafter called "Bar") was an adjuct to another utility (hereinafter called "Foo"). Foo reported all errors and many other usage tidbits about our software to our servers (which the business customers agreed to - it's not spyware). Foo worked great, provided a lot of useful information, gave our company a fantastic window into how the end-users were screwing up - I mean using our software.

However, Foo gave us too much information - an enormous amount of errors to sift through to decide which we would fix. That's where Bar came in.

Bar would look at Foo's data, apply some business rules, and automagically add the errors to our bug database (a separate vendor's product). Bar would run as a service, periodically converting raw Foo data into usable bug reports.

So Pete thought long (30 hours) and hard about Bar. And this is what he came up with:

  • 6 pages of diagrams
  • 11 pages in the design document
  • 28 pages of UML listings
  • about two dozen classes

All in Microsoft's VB.NET language.

And what did Bar really do?

  1. Look at one table
  2. Apply business rules
  3. Add or update records in a tracking table
  4. Add records to bug database

Four simple, straightforward things. Bar touched four different things (the service component is so ridiculously simple I don't include it). Bar was so simple that I could actually run half of it manually by using the database commands (very slowly, but I could walk through it - most of the logic was in stored procedures).

So I wondered why I needed 28 pages of UML listings, and 6 pages of diagrams, and around 2 dozen objects.

My decision

After looking at the amount of code (and the incredibly convoluted design), I decided to use Python. Simpler, easier to program, quicker to deploy. There were at least 2 different SOAP libraries from which to choose. I had only to code the service component in .NET.

The argument

On Pete's 2nd-to-last day, I informed him during our staff meeting that I would code Bar in Python.

Pete began talking, and didn't stop. Here are the highlights.

  • Complained about dropping 30 hours of his design work
  • Would not fit into the "Microsoft-only" network at the company
  • "We could script it in VBScript too"
  • Bar uses an object-oriented XML-serializable dataset approach to enable future workflow improvements

Some worthwhile arguments, some sarcastic, most narrow-minded. I leave it as an exercise to the reader to determine which was which.

Then Pete got personal. He told me to not be afraid of learning a new language (conveniently ignoring the fact that I had no problem, as evidenced by my knowledge of Python). He said adding .NET to my resume would be an improvement over "just VB6 and Python."

I stopped him at that point, very angry that he was so unprofessional as to bring my resume and career into an argument about which programming language to use.

The result

Our boss (out of the office, contacted me that afternoon) wanted me to continue programming in .NET, even though he acknowledged that Bar would have been a great test of using Python in the company. So I tried to make sense of Pete's convoluted, cock-a-mamie "decorator pattern" design. And failed.

Four days after that argument I told my boss, in another staff meeting, that I did not understand Pete's design. After struggling with Pete's code design (I had already created the database and coded the stored procedures) for over two days, I told my boss that I had very little understanding. I had thought that seeing code stubs would make it all fall into place, but it did not.

My boss told me to document Bar's status, post the information on our intranet, and move on. He was very displeased with me (subject for another entry).


So that's what Microsoft employees do when they cannot win an argument on the merits - they go directly to personal attacks.

Pete, you burned a bridge. Permanently. I lost a lot of respect for you when you attacked me.

Written by Andrew Ittner in misc on Tue 17 February 2004. Tags: business, commentary, python, technology, employment