Saturday, October 18, 2008

Fun times, Kind of a Blur Now

I think there were a lot of misconceptions about Microsoft from those software developers who are in the ABM (Anything But Microsoft) crowd. Microsoft was often viewed as this monolithic giant (aka The Borg) of ruthless win-at-all-cost people. In truth, most of us worker bees just liked working hard and launching products and it was up to the "Upper Management" to make the business succeed. Critics need to keep in mind that Microsoft is full (and I mean full) of really smart employees who represent a wide gamut of beliefs and opinions. This is just one opinion...

The Microsoft of Then

I started at Microsoft as a contract developer in June, 1994 while I was finishing my Bachelor's Degree in Electrical Engineering at the University of Washington. I already had a 19.5 hour-per-week job as a professional Systems Analyst Programmer (SAP III) for the C&C (Computing and Communications) which runs the IT infrastructure of the University so I had two jobs and a full load of credits during this period. I would periodically sleep in my car, on the lawn next to the softball field, in my office, etc., and often times wake up and not know where I was.

Fun times, kind of a blur now.

In December of 1994, I was offered a developer position in the group where I was contracting (Hardware). The next morning, I got married to my girlfriend in the Seattle Courthouse and later that morning walked into my boss's office and accepted the position and went back to work. Yes, that's right, I got married and went back to work.
That is how much I LOVED working at Microsoft
Now you can criticize me for having my life priorities out of whack and you would be completely 100% correct, but during those years Microsofties worked 80+ hour weeks. A few years ago I read an article about two Google employees getting married and going back to work... I did that ten years before and it wasn't news worthy: You know what Google, we used to love writing code and kicking ass too.

Fun times, kind of a blur now.

Here are a few of my projects:

Xbox Live

I was one of the core designers of the original Xbox Live. There I designed and wrote the functional specification for many of the marquee features (voice chat, voice commands, friends, notifications, etc); managed the feature teams of very hard technical challenges (networking and security, authentication and authorization, etc); and managed a team of PMs. As an interesting side note, the Xbox Live IANA Port is registered in my name (http://www.iana.org/assignments/port-numbers) and my Xbox Live Gamertag is 'd'. Invite me if you're online although I don't have much time to play anymore.

The coolest thing the team received was an Emmy Award.




2005 TECHNOLOGY AND ENGINEERING EMMY AWARD
Outstanding Achievement in Video Gaming Technology and Applications
for Development of Multiplayer Console Technology
XBOX LIVE
Presented to
Microsoft

Xbox Entertainment Network

I left the Xbox Platform Team to be the Technical Lead of the Xbox Entertainment Network. This was an incubation effort to bring downloadable, episodic content to the mass market and then later worked very briefly on the launch of Xbox Live Arcade.

SideWinder Game Voice

There were a few other fun projects such as SideWinder Game Voice (http://www.microsoft.com/presspass/features/2000/aug00/08-24gamevoice.mspx) where I was the architect and lead developer and Microsoft ActiMates (http://en.wikipedia.org/wiki/Actimates) where I was lead developer.

Patents

Here is a list of my granted patents while at Microsoft (there are eight more pending):
  • 7,389,153 -- Enabling separate chat and selective enablement of microphone
  • 7,370,194 -- Security Gateway for Online Console-Based Gaming
  • 7,311,608 -- Online Game Invitations using Friends List
  • 6,935,959 -- Use of multiple player real-time voice communications on a gaming device
  • 6,928,329 -- Enabling separate chat and selective enablement of microphone
  • 6,905,414 -- Banning verbal communication to and from a selected party in a game playing system
  • 6,807,562 -- Automatic and selective assignment of channels to recipients of voice chat data
  • 6,717,569 -- Control device with enhanced control aspects and method for programming same
  • 6,510,513 -- Security services and policy enforcement for electronic data
  • 6,317,714 -- Controller and associated mechanical characters operable for continuously performing received control data while engaging in bidirectional communications over a single communications channel
  • 6,067,095 -- Method for generating mouth features of an animated or physical character
  • 5,977,951 -- System and method for substituting an animated character when a remote control physical character is unavailable
Fun times, kind of a blur now.

From a product development perspective, this is why Microsoft does what it does and how it does it, good or bad:

The Microsoft Triad

The core product development team at Microsoft is made up from three different components which are treated as peers:
  • Program Management
  • Development
  • Testing
This system was designed with the old way of releasing software: an 18-36 month grind for Program Managers to add features to an existing product, developers to implement those features, and testers to test those features.

We would eventually win by Version 3 because we had very good, hard-working employees, a process and history of knowing how to ship large, complex software products, and lastly our competitors were on our platform.

This structure is exactly why Microsoft products are feature heavy and take so long to release, because Program Managers add value by creating features and then managing the team to release them. It would be shocking (and a career limiting move) to produce a Functional Spec which said, "For the next 18 months, we are not going to add any more features and instead make the ones we already have work really, really well." I should know, I was a developer turned program manager turned back into a developer.

That was the Microsoft of then.

Until a few years ago there had always been an analogous technology to every product category our competitors launched. If IBM or Oracle or Borland had something good, we would have something exactly like it eventually and overtake it a few iterations later because we could apply more resources longer.

The Microsoft of Now

Now with online services there are Operations employees who are part for the core team but very little has changed in terms of product development. We are still in the mindset of Program Managers write Functional Specs => Developers who implement functional specs => Testers which test against both Functional Spec and Engineering Specs (if they exist) => Operations which deploy these services. Product Planners look at an 18+ month time horizon even in some of the most "agile" groups.

What this leads to is larger teams taking longer to launch. A diametrically opposite viewpoint is proposed by 37signals, the folks who created Ruby on Rails, Basecamp and Campfire:

https://gettingreal.37signals.com/toc.php

While I don't agree with every point they've made, I think every Microsoft employee should read this and decide for themselves how they can incorporate some of this viewpoint into their product development process. Because there are more and more massively popular sites and technologies "out there" which have no Microsoft analog or a lame simulacrum at best:
  • YouTube, Facebook, LinkedIn, Twitter, Digg, etc
  • Ruby on Rails, Ruby Gems, RubyForge.org, Merb, etc
  • Amazon's Web Services (EC2/FPS/S3/etc)
  • git, github, lighthouse, basecamp, campfire, etc
  • package managers such as apt-get, yum, rpm (and lots of free packages to install)
  • End-to-End solutions such as the iPhone instead of the OEM model
Which makes me think:
Even worse then vilified for our success is being made irrelevant by our competitors
Does anyone fear us anymore?

All of that said, I believe that what made Microsoft successful for its first 30+ years will be its limitation for the next 30 years.

Has the Win32 API become the new COBOL?

When I graduated from school, there were these old-school programmers (for some reason they were overweight with beards) who commanded large paychecks to work in banks and large companies maintaining legacy COBOL applications. I always thought that the money would be nice but the job was programming purgatory. Besides, who learned COBOL anymore?

Now, I see brilliant Computer Science students come out of the university with experience in web development, startups, venture capital, social networks, mobile phones, Java, Linux, PHP, Python/Django, Ruby on Rails, etc. It is a rare exception to find someone under 24 with Win32 or ASP.NET experience. Although I'm thin with a beard, had I become this new generation's COBOL programmer, that is, I can command a good salary to work on Win32 client applications in banks and large corporations which is the type of programming I used to detest?



No comments: