So yesterday I decided to spike the FilteredCompletionList feature.  Now we need to decide where to do with it.  It might seem obvious, "just ship it!", but in actuality the process is a whole lot more complicated.  First of all a feature never exists in a vacuum.  To go from code into the actual product is normally pretty long and complex, even for a relatively simple feature like this.  

First, there's the code behind it.  This is usually the easiest part but by far the riskiest.  Why?  Well, that code i just added has the potential for bugs and bugs mean we could do something that screws you up while you're working and annoys you, all the way to us crashing and making you lose all your work.  Considering that this feature will be invoked every time you type a character it could be devastating to a user if there was a bug in it.  Now, while i trust my code (mostly) it sits on top of and talks to a whole lot of other components.  A single bug in those could end up causing problems in the end feature.  So what do we do about that?

Well, besides testing by the devs we also have a dedicated team of QA who takes a freakish pleasure in finding bugs in our code and showing everyone how incompetent the devs are.  However, QA absolutely has their schedule completely full.  They've been covering every other feature and have majorly complex systems like refactoring and EnC to test.  So to get this feature in probably means that we'd have to sacrifice the quality of testing that the rest of the product undergoes.  However, if that wasn't bad enough there's another person who needs to be involved:

We'll need a PM to sit down and really think about this feature and decide if the current implementation is really what we want to do.   This is actually a surprisingly hard job.  As you saw in the previous blog lots of people have lots of different ideas about how completion lists should work.  Some astute readers made the realization that we were combining a lot of different concepts together and perhaps it would make sense to have dedicated tools in the IDE that excelled at these task rather than a mishmash jammed altogether where it doesn't belong.  The PM also has to think about the future.  If we go down this path then we have to keep this feature in the future.  That significantly limits our ability to come up with flexible solutions here in the future.  If we add "sorting based on locality" then we'll have to decide how to fit it into the current UI and potentially aggravate users who like this model.  The PM will also need to figure out how this feature fits in with all the rest of the features that ship in VS2005.  These completion lists won't behave the same way as VB or C++, is that ok? etc. etc.   All in all, i consider this job to be the toughest because there are rarely ever any "right" answers.

Say we do decide to go ahead with it.  Then we'll presumably want to great options to turn it off/on, and that means that we'll have to repeat all of the above for just the options UI.


What's worse is that the C# team just hit ZBB.  We've smashed through all the issues assigned to us (both internally and from the msdn site) and we're working very hard to make C# as stable and high quality as possible so we can ship it to you ASAP.  Adding a feature like this adds a lot of risk to those goals incredibly late in the game.  However, if we don't ship this feature now then you won't get it (at least without an add-in) until the next version... if then... :-(

Frankly, that depresses the hell out of me.  It's clear that developers want these features and they play a large part in their satisfaction as well as their productivity, but we're not delivering for you.

So what can we do about that?

Well, we've been discussing an idea in the office that we call TweakC# (in reference to TweakUI.exe which ships with the Windows PowerToys).  This would be a little tool that you could download that would expose options for you that you could enable/tweak in order to get extra functionality.  Like the PowerToys these would be completely unsupported and any modifications you made would be at your own risk.  I would give my personal pledge to work hard to make sure that those features were stable and crash free, but that's about all you'd get.  We'd also try to make it so that the TweakC# tool would have a "reset" option to restore your original C# settings, but that depends on how much time we had.

In essence we'd be keeping the code in for some features that have been written by devs here but we'd be disabling their code paths through the use of registry keys.  These features would include things like filtering completion lists, bash style autocompletion, smart parse-tree aware selection, spell-checking, etc.   The TweakC# tool would basically just be enabling those reg keys which would then open them up to you.

By doing this we would be removing two of the very costly portions from above.  There would be no QA coverage of the code, and there will have been no PM consideration of the feature.  That means that it would be quite possible for there to be large instabilities in the code and that the feature could go the way of the dodo for the next version (although i doubt it).

Would you guys be ok with a model like that that presented you with these new features in an unofficial way?  Or do you think that if it's not something officially supported then you don't want it?

Let me know!

Edit: Instead of making the "Tweaks" just registry keys that were flipped, what if we provided a new cslangsvc.dll to download that would replace your existing one.  That would make sure that the current dll you get out of the box isn't affected by these tweaks.  The dll you would download would use the registry as well.  That way if one of the tweaks was unstable (or slow, or undesirable), you could just disable it and keep using the other ones.

Note: this method has a lot of *scary* issues associated with it.  Most specifically is the issue of servicing.  if we release an update "out-of-band" from the regular VS update process then it's not clear what problems might occur if you then try to install a service pack later on.  Of course... we've never shipped a 2k3 service pack... so maybe that won't even be an issue ;-)