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 😉

Comments (38)

  1. Yes – Definately! A Tweak-like utility would be a great idea.

    Worst case scenario is that it doesnt work, and the user’s turn the feature off…In the end, they’re really no worse off than they would have been if the functionality wasn’t provided in the form of a tweak, because the functionality would never have made it into the product in the first place.

    At lease this way we get something!!

    Great work!!

  2. Kirk Marple says:

    I think this is a great approach. Keep the core IDE tight as can be, but extend it in some useful and innovative ways – but be able to turn those pieces off if they end up being less than stable.

    Main question would be, how hard is it to download new fixes for the tweaked bits? If it’s just copying over some DLLs or running a MSI, i’d be up for it.

    I’ve been using VS2005 for the past month or so on our next version, and it’s *really* hard to go back and do dev on our current code tree which uses VS2003. The new IDE is just *so* sweet in comparison.

    I love the Intellisense (so much better than VS2003), the color coding, and the code formatting.

  3. Firstly, I just subscribed to your blog. You have really interesting content.

    Secondly I think that it’s a great idea, and that running with that type of model would more than likely suffice for most developers (as most developers love playing with settings and tweaking their environment anyway).

    Are you entirely sure that this wouldn’t need to be run through your PM? 😉 Think about it, even though the code paths are cut out of the mainstream app, isn’t it their business to decide if (even when enabled) it is going to cause problems or not? And how much flexibility you want to give the user, and if its going to effect their user experience (even if unsupported)? What about their views on deployment size. If the app was completely bewildered with things that people simply wouldnt use on a day-to-day basis it might very well end up becoming less maintainable, etc.

    However, if you could completely abstract it from the app all together and put in all a design for pluggable access to the internal API of the environment, that would be a lot better. I guess that has already been done with the addins feature or even macros for that matter. Is it not possible for these types of feature-adds to come in as addins?

    Just some thoughts anyway…



  4. damien morton says:

    Sounds good to me.

    #define NOBUGS 0

    roll your socks down, set your hair on fire, and make sure you keep both feet on the wheel.

  5. Gavin Morris says:

    I share some of Matt’s concerns, but my fascination with the bleeding edge overrides them. Sounds like a fantastic plan. Bring it on!

  6. The notion that you can add code, even in dead code paths, with zero risk of impact to other features strikes me as pure hubris. I don’t think this is worth the even vanishingly small risk of destabilizing something else. If a feature can’t be run through a full cycle of PM, dev, and test, don’t put it in the box.

  7. Jens says:

    Maybe you could talk to the VB.NET team and see if they can make a Tweak VB so that we also can get Refactoring (it’s still not fair that C# gets EnC but Vb does not get Reafctoring).

  8. Mike: Thanks very much for taht excellent feedback. It’s good to know that for you the stability and quality of what we’re shipping should not be compromised.

    I’m going to update the blog with a new model. tell me what you think about it.

  9. Jens: If it makes you feel any better, C# still doesn’t have incremental compile (or a lot of teh other new features that VB is adding this version).

    You’re right that it isn’t fair. But trust me there isn’t any malicious intent involved, merely a matter of resources. No team has the time and other resources necessary to do everything we want (heck, this entire blog post is about that), and so we have to figure out how to best allocate those resources.

    Sorry 🙁

    (sorry to all the C# users too who want, but haven’t gotten, features from VB in C#)

  10. Duncan says:

    Heh – the download and replace dll model sounds good. I guess that way these ‘Tweak’ features could keep being developed and released on an incremental basis throughout the lifespan of the VS release.

    Kind of a rolling alpha/usability test for users who can accept some breakage of their environment from time to time and who know that the features may disapear in the future.

    And yes it is a shame that the VB and C# teams haven’t come together and worked on producing the same IDE with a simple syntax change yet (or at least that’s the way it sounds – don’t hold it against me if I’m just reading way too much into way too few comments).

    Roll on TweakVS options.

  11. Zhaph says:

    Yes please – I think the replace version may be a better option, but I’m interested in either 😀

  12. Luc: "This approach may also provide you with more feedback from end-users for ‘Whidbey service pack 1’ 🙂

    The only thing to think about is to what level it is ‘unsupported’: would you allow feedback for it on LadyBug or not. "

    Yes, you can give *any* constructive feedback on ladybug. Information about these enhancement (if they suck, if you love them, if they could be slightly better, etc.) will be well appreciated and will ensure that later versions become better and better for you.

  13. Duncan: "Heh – the download and replace dll model sounds good. I guess that way these ‘Tweak’ features could keep being developed and released on an incremental basis throughout the lifespan of the VS release. "

    Yes, many new features could be added, but just as long as they are only contained in cslangsvc.dll (or any of our managed dlls). So if we wanted to make a change that would require other interfaces in VS to change, then we wouldn’t be able to. But there’s still a lot we can do just within our own space.

  14. RichB says:

    Go for it! Do it with Registry keys.

  15. Samuel Jack says:

    I’m all for it. Either way would be fine, but shipping the cslangsvc.dll sounds like a good idea. It’s very sad that time between VS releases is so long: this would be a way to make the gap seem shorter!

  16. Sean Malloy says:

    I love unsupported features! Business development I wouldn’t touch it, but for stuff at home and for fun, bring it on.

  17. Sam says:

    I’d rather not risk instability of c#/the IDE with any feature, so I’d opt for the ‘download the patched dll’-option.


  18. Philip says:

    You know the worst thing about the VS2005 beta? After using it, its impossible to go back to VS2002/3 and feel comfortable there. The IDE features in VS 2005 pretty much blow away the previous 2 versions!

    Now I’m stuck waiting until VS2005 releases, and saving up my rupees for the Standard Edition!

    Oh well, at least I have Express to play around with 🙂

  19. Marcus Stade says:

    I’d like to agree with people’s concern for stability and say that a patched version might just be the way to go. Or an add-in for that matter.

  20. Way to go. I’ve been begging for MS to do more of this kinda stuff when they have a feature that doesn’t have much more cost as far as dev, but QA, approval, etc. etc. bring it down. Or when the feature might not please everyone. I’m so happy to see you thinking about shipping a feature that can be flipped on for those who want to. Just listing the registry keys is fine. Hell, even telling me how to patch the dlls would be fine. TweakC# is just gravy :).

  21. Ron says:

    I’d rather see the TweakVS route for this functionality. Not because I’m afraid to plop in another dll, but because I’d be concerned about the long term viability of doing so when you clearly see the possibility of patches for VS coming down later. If you have a replacement dll with these new features, now you’ve introduced a separate patch path based on which version the user may be running. Meaning, how will the replacement dll be created such that it meets the same level of reliability of the core functionality?

    Does that make sense?

    Someone either has to maintain the replacement dll with the same level of testing against it or the new functionality must be imported into the certified patched original dll code. By keeping it all in one dll, the core bits are tested appropriately. This also allows the possibility of more time for testing and creating new tests for the additional features. Yes, I know patches aren’t supposed to introduce new features. Perhaps if it’s included from the start, it won’t be considered a "new" feature.

  22. Jim Argeropoulos says:

    I think I would prefer the dll replacement model. Just be sure you have some approval from within before embarking on the task. I would hate for you to get into hot water over the deal.

  23. JS says:

    I really like the idea of TweakC#. However I would activate it with registry keys. Replacing dll will results in a nightmare of problems if you ever ship a service pack… Some users *will* install the wrong version of the dll.

  24. Yes, yes, yes. I would prefer the dll solution, but I’d take it any way I could get it. I like these types of tools. I understand that there is a large section of the populace that can’t deal with the issues, but when you release them it makes life easier for the rest of us.

    If this is electronic voting, please count my vote many times.

  25. Haacked says:

    How difficult would it be to provide these features via the extensibility model, i.e. as add-ins.

    That seems to address most of these concerns assuming it’s not too much work to port the features to an add-in model.

  26. BMoscao says:

    I think that getting this feature in a Tweak style is better than not getting the feature.

    The replacement dll seems like a good idea.

  27. blameMike says:

    I’d really like to see this feature, and if the only way we’re going to get it is with an unsupported method… so be it.

    The onus should be on the end user if they chose to enable, therefore negating MS’s need to support it. In other words… use at your own risk.

  28. Shital Shah says:

    Oh Sure! I’m so damn ok to get those power tweaks!

  29. JavaKid says:


    The idea of allowing users to control/configure their environment is wonderful. Better yet is the idea of releasing changes to the customer (developers) on a more frequent basis.

    Whether these releases are done as you suggest in the latter paragraphs of a previous post:

    or as part of an unsupported control mechanism "TweakC#" doesn’t really matter to me. You are making the right kind of progress… I am very happy to know that you are within the Microsoft walls, and keep up the good work. Have a good time away from the office this month 😉


  30. AT says:

    We now have Express, Standart, Proffessional and Enterprise editions of VS.NET

    How about one more – VS.NET 2005 Hacked Edition.

    Hacked mean that it has a lot of hacks from Microsoft developers and third-parties.

  31. ChrisBro says:

    I would probably only use this if it was a registry key. Maintaining patched DLLs is a significant additional headache. And I think that, from a security perspective, it is not good to encourage "if you want new functionality, download this arbitrary DLL to replace one of your system/app DLLs!". The registry exists to get around that problem. And, on a machine shared by multiple users or for a user who isn’t running as Admin, replacing the DLL is not an option but setting a regkey in HKCU is.

  32. Duncan says:

    ChrisBro : Whilst that is true, what happens then if Cyrus finds a showstopper bug in his non QA’ed code? It would render the tweak useless. OTOH if it was a replacable dll then he code fix it and make it avaiable to us without having to wait till the 2007 (or later) refresh.

  33. Cyrus,

    as long as there’s a ‘reset’ option, i’d at least try that stuff. that is, i’d try anything that doesn’t change the compiler itself: i won’t have any code using language features that aren’t fully supported. i don’t mind unsupported ide features though.


    thomas woelfer

  34. mirela says:

    Very nice blog. It is very helpful.