How many Microsoft employees does it take to change a lightbulb?
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.
Comments
Anonymous
October 28, 2003
What a fantastic argument for Open Source!Anonymous
October 28, 2003
Who develops the test plans for open source software? Who updates the screenshots in the user's guide and online help? And who translates the documentation into Polish and Turkish? Who verifies that the feature doesn't violate the Americans with Disabilities Act or German privacy laws? (Back when I worked on Linux, the answer was "Nobody. There is no test plan, there is no printed user's guide, what little documentation there is exists only in English, and nobody cares about complying with the ADA or German privacy laws." Maybe things have changed since then.)Anonymous
October 28, 2003
I'm not following you Robert. Thought experiment: tomorrow, Bill open-sources all Microsoft products and set up a hundred billion dollar endowment fund to pay for continued development of the codebase. What makes all of the costs I mentioned suddenly go away?Nothing! Open source isn't magic. There seems to be a strange belief amongst the open source community that just because you can make a change to the source code, and no one pays you to do so, that the change was free. But it wasn't, because changes don't cost money. Changes cost EFFORT to do right, and money is just a convenient way to measure effort, not effort itself. There's only a finite amount of effort in the world, and knowing how to apply it to greatest effect is a difficult problem. It doesn't take a couple dozen people to change a lightbulb here because we sell software for a living -- it would take those couple dozen people even if we gave it away with the sources. It takes a couple dozen people because we deeply care about that legally blind Catalan-speaking customer. It takes a couple dozen people to change a lightbulb because software is an insanely complicated device that runs in an insanely complicated world. Managing that complexity is a lot more work than changing the code.Anonymous
October 28, 2003
The point is that the customer is free to fix/alter that which affects themselves, but isn't worth fixing to you. Since the feature/problem isn't worth it to you, it obviously follows that the feature isn't for widely deployed software... where all of your effort is (rightly) focused. It just needs to work on a small number of boxes for a very specific purpose, where the blind Catalan-speaking customer doesn't come into play. Or perhaps the feature is very very important to the customer (yesterday! dangit!), and they don't have time to wait for MS to QA on Windows XP Home Arabic.Anonymous
October 28, 2003
Got it. But this is precisely why we built the script engines to be extensible by arbitrary third party ActiveX objects. Like I said, if the feature is cheap and easy, then implement it yourself in a VB6 object. But the script engines themselves cannot be allowed to fracture into a million slightly different mutually incompatible versions -- that doesn't serve customers well.Anonymous
October 28, 2003
The comment has been removedAnonymous
October 28, 2003
I believe MS already ships quit a significant amount of "open source" software in the form of all the samples in the msdn online, and the samples included with the various product installations, such as VB.And if that is not enough, you can find tons of samples online, in various trade publications, in newsgroups and obviously in blogs like this one.OTOH you cannot ignore the fact that Microsoft becomes somewhat liable for any piece of software it ships regardless of how unofficial it is. If you copy a sample for this site and it formats your disk, you will blame Microsoft and Eric could loose his job.Anonymous
October 28, 2003
The comment has been removedAnonymous
October 29, 2003
You missed one step - three people to argue about whether this method is safe for scripting :-)Anonymous
October 29, 2003
Raymond wrote: "Who develops the test plans for open source software? There is no test plan, there is no printed user's guide, what little documentation there is exists only in English, and nobody cares about complying with the ADA or German privacy laws." Maybe things have changed since then"They certainly have changed. If you're interested in whether this is true, check out the Gnome and KDE projects. Much more organised (esp. KDE) than they ever used to be. In general it's work that most OSS developers don't want to do - it's not an itch to scratch to use the cheesy phrase I keep hearing. Now that there is interest in OSS and money is being thrown about, people are working on these things because they are being paid to do it.Eric seem to be arguing (please correct me if I am wrong) "How do we pay for peoples effort if we give everything away"? Well for a start OSS does not mean free. Just because some OSS apps are free doesn't mean they have to be. I wonder how many Microsoft employees have actually ever been to opensource.org and can now argue about OSS without resorting to the usual FUD we get from Microsoft. I'm not deliberately trolling here, I like OSS and I also like Windows, but when I see the FUD and things like the underhand funding of SCO I don't like MS. It's like they don't want to compete on fair terms - maybe I'm just naieve and that's how business works. I hope not.I have to say about the user guide and it being printed, I have NEVER seen anyone read it. No exageration. Never. Ever. Maybe you should do a poll, you could save money by not printing it :)Anonymous
October 30, 2003
geeks doesn't read it. joe user does.Anonymous
October 30, 2003
> Eric seem to be arguing (please correct me if I am wrong)"How do we pay for peoples effort if we give everything away"? No, I'm certainly not arguing that. Perhaps Raymond is, but I am not. I realize that there are companies that pay people to work on open source.My argument is that IF you are in the business of writing software that is to be used by millions of people around the world, THEN the primary cost of implementing that software is NOT in the implementation. The cost is in the design, the review, the documentation, the testing, the maintenance, the support calls, etc. Whether your business model calls for selling that software or -- as we did with the script engines for the last seven years -- giving it away for free, whether the source is open or closed, has not the least bearing on my point. Does the open source model work well for one-off changes that will be distributed to one person? Obviously. But that's not the kind of change I'm talking about.Anonymous
November 01, 2003
Opportunity costs are hypothetical. "Stealing" refers to the act of depriving someone of actual property. As a hypothetical is not actual property, "stealing" is a poor word to use in your last paragraph. Better to let the facts stand up for themeselves instead of concluding with a false characterization.Anonymous
November 03, 2003
> Better to let the facts stand up for themeselves Actually, "facts" are abstract entities which do not have legs. So they can't really "stand up" for themselves. That's kind of a poor choice of words, wouldn't you say? Fortunately, by using my advanced skills in inference I can probably figure out what you intended by your imprecise and colloquial expression. :-)Anonymous
November 05, 2003
You can tell that these are only techs reading this because hey guys! (particularly Robert, etc) - End-users don't want half-baked software!!! While as a dev, I would gladly rather have the software do what I wanted it to, I would also rather have it do what it can do (without causing more problems), and allow me to change its behaviour.Just because Tech Guy down the street can change the behaviour of an application doesn't mean that all end-users can. We, in the tech community, are in a position where we not only "see" the final result but also see how its made and can affect change. End-users, although this attitude is sometimes changing, don't care how it works - they just want it to.When I ask the time, I don't want to know how to build a clock nor how to fix the clock - I just want the clock to tell me the time. Open Source isn't a solution for the problem mentioned above- it's simply another take on it.Anonymous
November 11, 2003
"Just because Tech Guy down the street can change the behaviour of an application doesn't mean that all end-users can."Admittedly not, but at least they would have the opportunity to pay/hire someone to do it for them. If I want someone to add something to my house heating system, I want ANYONE with the skills to fix it to be able to fix it, I don't want to be FORCED to go back to the original installer ....Anonymous
February 23, 2004
So the Answer is "41 at a minimum"?Anonymous
May 26, 2005
It looks like the intricacies of higher-dimensional geometry will have to wait another week; I am incredibly...Anonymous
June 25, 2005
John Gruber makes an appearance in the soon to be released book The Best Software Writing I which was put together by Joel Spolsky .Anonymous
July 18, 2006
Whether it's software or content, making a change can often be a much bigger deal than you'd think. I...Anonymous
August 16, 2006
PingBack from http://pschmid.net/blog/2006/08/17/38Anonymous
August 16, 2006
Eric,
just wanted to make sure you saw my response to your comment on my blog:
well deserved feedback. I remember vividly that I made the argument that a certain bug fix for Outlook 2007 would only be a few lines of code (I stopped short of volunteering to write the code for the devs) without knowing how much other work would be associated with those few lines.Anonymous
December 20, 2006
The comment has been removedAnonymous
December 26, 2006
PingBack from http://www.christopherjbaker.com/?p=97Anonymous
March 15, 2007
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.Anonymous
April 10, 2007
PingBack from http://www.jtheo.it/2007/04/11/a-proposito-di-software-joel-spolsky/Anonymous
April 21, 2007
PingBack from http://www.livejournal.com/users/jace/385188.htmlAnonymous
April 21, 2007
PingBack from http://www.ljseek.com/introduction-to-best-software-writing-i_61114144.htmlAnonymous
May 09, 2007
PingBack from http://www.alejolp.com/blog/2007/05/10/querido-microsoft/Anonymous
June 05, 2007
PingBack from http://blog.rushchak.com/index.php/2007/06/06/joel-spolsky-best-soft-book/Anonymous
July 10, 2007
Sounds so similar to bureaucracy!Anonymous
July 23, 2007
The comment has been removedAnonymous
July 23, 2007
The comment has been removedAnonymous
July 27, 2007
PingBack from http://ggierlik.wordpress.com/2007/07/27/gdzie-chcesz-pracowac/Anonymous
September 07, 2007
It looks like the intricacies of higher-dimensional geometry will have to wait another week; I am incrediblyAnonymous
September 10, 2007
PingBack from http://jdilelle.wordpress.com/2007/09/10/voulez-vous-collaborer-avec-moi-ce-soir/Anonymous
February 15, 2008
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. :-)Anonymous
April 04, 2008
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.Anonymous
October 15, 2008
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...)Anonymous
March 30, 2009
Love it! I tired telling my managers how much time a little bug may take to fix and get on production. :-)Anonymous
May 12, 2009
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.Anonymous
May 18, 2009
The comment has been removedAnonymous
October 20, 2010
The comment has been removedAnonymous
October 20, 2010
The comment has been removed