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.

  • It doesn't take a single employee to change a lightbulb, Bill Gates just redefines 'Darkness' as the new industry standard...

    (it was in my englishbook bill...)

  • Love it!

    I tired telling my managers how much time a little bug may take to fix and get on production. :-)

  • I can see the point you're making in the article. In fact this is why I value stuff coming from Redmond so much. It actually is tested, some API concerns are taken into account and above all one can actually find some real-life examples of how to use a particular part of the system.

    No wonder it takes so much to implement such a trivial thing.

    A note about open-source frameworks: they are great, even fantastic! But the best ones have extensive documentation and a fat set of examples. The ones that don't have that learning resources, even if they are best in the issues they are solving, are doomed to be used once, maybe twice.

  • I totally agree with this article. People too often do not realise that a simply change can cause such a huge side effects. Our website is in 16 languages, we have accepted that some text (on some pages even majority) is not translated, because traslating it caused more grief than happines. For example translating some text caused grammatical errors (consider plural form - in English is easy, 1 photo, 2 or more photos, buut in Polish is 1 zdjecie, 2 zdjecia, 5 zdjec, 12 zdjec, but .. 22 zdjecia, however 21 zdjec, etc) and caused a flood of complains, which created an extra task of answering them, which ... costs time==money

    @bob - of course you have free development tools (on MS platforms - Express editions, on Linux Eclipse, etc)

    @open source supporters - I love some opensource stuff, but you must accept that if someone makes changes which are just for him they have to accept that the WHOLE modified product cannot be then properly supported, as their small change in the code might have a knock off effect in a very unexpected place. I have developed many libraries in my life and I know from the painful experience that you will get errors in totally unexpected places.

    One the strangest erross we have had had a following scenario (code written in C, many years ago). User input was accepted as a number, including decimal comma. Then we introduced localization allowing decimal comma, routine was scanning a number changing comma to dot, like while(*ptr!=',') ptr++; *ptr='.'.

    Of course once it happenned that users input did not have a comma and code (it was C!) was continuing happyly beyond array and ... found value 2c on the stack and converted it to 2e. It happenned to be return address, so as the effect next line after the call of this routine was not executed, and this skipped was a short jump out of the loop, so external loop executed once more and customer name was changed to something else. It took us almost two days to find this problem.

  • It's a classical example of how when a company gets bigger, it starts moving slower and slower (by necessity. MS ignoring any of the above points will almost guaranteed result in a lawsuit somewhere)

    Reading this, it strikes me that the software industry pretty much as a whole has no way of releasing features "along the way" to get better feedback. There's no way to release a simple, non-localized, non-vetted LightbulbEx, collect feedback, improve it, and only finalize it later - if it's indeed a crucial feature that everybody needs.

    And while I love OSS, it's not exactly the answer. You still need to move from that quick-hack version to the fully localized one, you have the issue of incompatibilities between different versions of your SW (which non-geek users don't exactly appreciate), etc.

    It's an interesting problem that hasn't seen a solution yet.

  • Maybe it's time to change the way you guys release your products - not that I know *how* you should change...

    I'm not following your line of thought. How does changing the distribution model affect the costs of design, implementation, testing, security review, documentation, translation, maintenance or management? Distribution cost is a cost that I did not even think to mention, so I don't understand why you're bringing it up. Can you explain? - Eric

Page 4 of 4 (51 items) 1234