How many Microsoft employees does it take to change a lightbulb?

How many Microsoft employees does it take to change a lightbulb?

Rate This
  • Comments 51

UPDATE: This article was featured in The Best Software Writing I. Thanks Joel!

Joe Bork has written a great article explaining some of the decisions that go into whether a bug is fixed or not. This means that I can cross that one off my list of potential future entries. Thanks Joe!

But while I'm at it, I'd like to expand a little on what Joe said.His comments generalize to more than just bug fixes. A bug fix is one kind of change to the behaviour of the product, and all changes have similar costs and go through a similar process.

Back when I was actually adding features to the script engines on a regular basis, people would send me mail asking me to implement some new feature.Usually the feature was a "one-off" -- a feature that solved their particular problem. Like, "I need to call ChangeLightBulbWindowHandleEx, but there is no ActiveX control that does so and you can't call Win32 APIs directly from script, can you add a ChangeLightBulbWindowHandleEx method to the VBScript built-in functions? It would only be like five lines of code!"

I'd always tell these people the same thing -- if it is only five lines of code then go write your own ActiveX object! Because yes, you are absolutely right -- it would take me approximately five minutes to add that feature to the VBScript runtime library. But how many Microsoft employees does it actually take to change a lightbulb?

  • One dev to spend five minutes implementing ChangeLightBulbWindowHandleEx.
  • One program manager to write the specification.
  • One localization expert to review the specification for localizability issues.
  • One usability expert to review the specification for accessibility and usability issues.
  • At least one dev, tester and PM to brainstorm security vulnerabilities.
  • One PM to add the security model to the specification.
  • One tester to write the test plan.
  • One test lead to update the test schedule.
  • One tester to write the test cases and add them to the nightly automation.
  • Three or four testers to participate in an ad hoc bug bash.
  • One technical writer to write the documentation.
  • One technical reviewer to proofread the documentation.
  • One copy editor to proofread the documentation.
  • One documentation manager to integrate the new documentation into the existing body of text, update tables of contents, indexes, etc.
  • Twenty-five translators to translate the documentation and error messages into all the languages supported by Windows.The managers for the translators live in Ireland (European languages) and Japan (Asian languages), which are both severely time-shifted from Redmond, so dealing with them can be a fairly complex logistical problem.
  • A team of senior managers to coordinate all these people, write the cheques, and justify the costs to their Vice President.

None of these take very long individually, but they add up, and this is for a simple feature.You'll note that I haven't added all the things that Joe talks about, like what if there is a bug in those five lines of code? That initial five minutes of dev time translates into many person-weeks of work and enormous costs, all to save one person a few minutes of whipping up a one-off VB6 control that does what they want.Sorry, but that makes no business sense whatsoever. At Microsoft we try very, very hard to not release half-baked software. Getting software right -- by, among other things, ensuring that a legally blind Catalan-speaking Spaniard can easily use the feature without worrying about introducing a new security vulnerability -- is rather expensive! But we have to get it right because when we ship a new version of the script engines, hundreds of millions of people will exercise that code, and tens of millions will program against it.

Any new feature which does not serve a large percentage of those users is essentially stealing valuable resources that could be spent implementing features, fixing bugs or looking for security vulnerabilities that DO impact the lives of millions of people.

UPDATE: KC Lemson and Raymond Chen and Chris Pratley have opinions on this as well.

  • PingBack from http://www.christopherjbaker.com/?p=97

  • So much about open source talk. Forgive me for my ignorance. Who uses open-source? I have heard everyone promoting it. Haven't seen anyone, at least in the develoment community that i have seen till date using any of those products. Let's not be hypocritical. You want to make something that people use, it costs. Listen nothing comes FREE.

  • PingBack from http://www.jtheo.it/2007/04/11/a-proposito-di-software-joel-spolsky/

  • PingBack from http://www.livejournal.com/users/jace/385188.html

  • PingBack from http://www.ljseek.com/introduction-to-best-software-writing-i_61114144.html

  • PingBack from http://www.alejolp.com/blog/2007/05/10/querido-microsoft/

  • PingBack from http://blog.rushchak.com/index.php/2007/06/06/joel-spolsky-best-soft-book/

  • Sounds so similar to bureaucracy!

  • As much as I love Open Source software, this arguement (the one made by the article-writer) holds true for Open Source software, too.  However, with Open Source software, you usually don't have the luxury of a Program Manager, multiple QA folks, etc all collaborating.  It's usually you and maybe a couple other dedicated folks passionately working on something.  You get done, you toss it out to users, and then tons of bugs show up that you never thougt about (who'd have thought the user's would stick the bulb outside in zero-degree weather...OOPS!)  So, in my opinion, this is not an argument "for" Open Source software.  Open Source software suffers from the same "how many does it take" syndrome.

    Getting back to the article writer's point, you don't want to toss all kinds of one-off crap into your project, because then it bloats up the project.  However, more and more projects opt for a foundation and then extensible scripting (EG: some video games, firefox, etc).  Of course, if your project is nothing more than a scripting language (VBScript), then it's meant to be light-weight.  So, yeah, suck it up and do the 5 lines of code yourself.  If VBScript got bloated with everyone's "one-off" junk, it'd be such a cumbersome hodge-podge of stuff, nobody would use it (or complain about how complicated it's gotten.)

    I think Bill Cosby said it best..."I don't know the secret to success, but the secret to failure is trying to please everyone."

  • Lots of folks use open source.  From the person who decides to use Open Office or Firefox, to the person who downloads a piddly little program or trainer to hack some game file so they can buff up their character.  Software is so ubiquitious and easy to make these days, that folks think it has to cost tons of time and money to make it still.  Open Source just means the source is viewable and (possibly) modifiable (depending on the license the author releases it under).   Open Source isn't necessarily free in some cases...folks can let you see the source, but still charge you to use it or the compiled program.  But, software isn't some commodity large corporations have sole entitlement to.  It's like regular writing...anyone can do it, and lots of folks do.  Whether you choose to buy a book from the store that has the info you want, or get the info for free from an internet site is a matter of choise.  Free doesn't necessarily mean "bad" or "poor quality".  However, in United States especially, folks think the more something costs the better it is.  So, there's still a frown on Open Source and Freeware.  It's like saying only the expensive Dealer can fix your car, because the shade-tree mechanic down the street doesn't know anything.  On the contrary, the shade-tree mechanic may know a lot.  Then again, he may not.  There's a greater variance in quality with the shade-tree mechanic, but you can still get poor service from the Dealer.  Quality is not a given just because you pay money for a product or service.  And, inversely, poor quality is not a given just because you get something for free.

  • PingBack from http://ggierlik.wordpress.com/2007/07/27/gdzie-chcesz-pracowac/

  • It looks like the intricacies of higher-dimensional geometry will have to wait another week; I am incredibly

  • PingBack from http://jdilelle.wordpress.com/2007/09/10/voulez-vous-collaborer-avec-moi-ce-soir/

  • I think the problem is that the development tools are not free.   Writing and ActiveX extension as the author suggests shows great extensibility, however, if I have to spend $500 or $1000 to get the tools to do this then it's a non-starter.

    Just one more reason Mac OS X with free developer tools is superior. :-)

  • The problem that Microsoft has is often scale!  When you have millions of people that depend on your project changes that normally are done without a second thought are now all of a sudden very difficult.  This is the huge dependency on product use.  Divide the number of people using your product by the number of people making your product and you might get a better idea of the efficiency of your team (not the best metric I know but it helps with perspective).  The second problem that is described is flow.  Most of the time described in the many week process is waste due to time waiting on other people.  If you had everyone in the same room then the task would be completed much faster.  Open Source is great, but Open Source has the same problems at larger scales.  These scale issues often cause the community to "fork" and that can make this better but can also cause fragmentation.

Page 3 of 4 (51 items) 1234