Fabulous Adventures In Coding
Eric Lippert is a principal developer on the C# compiler team. Learn more about Eric.
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?
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.
What if the user can't create an ActiveX object? Not becauser they can't code, but because they don't have access to the development environment, compiler, or sufficient authority to create and/or install the object? After all, VBScript (and JScript, VBA, WSH etc etc etc) is available to many more users than visual studio, or some other development tools.
You can argue that they should obtain the neccesary software/authority etc to develop ActiveX objects (and perhaps after 12 months the business case might get approved...). But a language that requires a business case to implement some needed functionality is essentially crippled.
I can say from personal experience that having a language not go "all the way" is as frustrating as the allusion implies.