I ask this question because C# 2005 is getting more and more solidified as we approach the release date. Adding new features at this point involves determing how much benefit the user will get out of it versus the cost to design, implement and test that new feature. As we get closer to ship date the feature has to get more and more compelling with less and less cost. This is an example of “raising the bar”. If we don’t keep that bar high then we’ll introduce something that we don’t have enough time to get to the quality that people want and we run the risk of destabalizing the product.
This also means that as time goes on features that are currently in the product might get cut. Even if they provide high user value, if there isn’t enough time for a dev to implement it it will be cut. If the dev can (or has) implemented it, but there isn’t enough time to test it, it will get cut. I’ve had this happen with three features that I added in my spare time. Anson and Kevin both experienced this as well. It’s kind of depressing, but with a limit on how many resources you have it just happens. I’d like to talk about those features to get some feedback on how useful people find them, but I’ll have to run that by Jay first to know if that’s ok.
However, when we cut something we don’t say “we’re not going to do that ever,” instead we say “we’re going to postpone work on that and come back to look at it later.” Then, when we add that to the list of things we want to do for the next version. When we get around to planning that version we prioritize those features, try to estimate how long it will take to add them and then we pick a subset of all the things we have that we feel will provide the best user benefit.
Features that are chosen then have a very high chance of staying in the product. Features added later have a much higher chance of getting cut because they add pressure on everybody later in the game when, most likely, all schedules are packed. Cutting current features to make time for the new features is a tough sell because of all the time already spent and also the risk of destabalizing when you remove that code. All in all it’s a tougher thing to do. Note: this is just a simplistic view of things from a dev’s perspective. Anson and Jay would probably be able to explain this a lot better from a PM and Lead’s perspective.
So, if you have features that you really want in the next version of the product, now is the time to ask for it. We’ll add those to the list and if they’re good then they’ll get done. Note: feel free to make suggestions about any part of the products, but know that we (well me specifically) are focussed on the code editor and compiler for C#. We’re very interested in everything else (like WinForms or the base class libraries), but other teams take care of those so they’d understand it better than we might. However, we’d send all of this information to the teams appropriate to handle it.
I might add that detail would be appreciated with the responses. Rather than just “add emacs support” explain in depth what aspects of emacs you really like and how they would benefit you substantially. For example, is it just the keybindings, is it something about the interaction model, etc.? You also don’t have to talk about humongous feature additions like “vs should add refactoring support”, you can instead talk about little things that drive you nuts in VS7/7.1. Like “i hate it when I’m typing and ‘foo’ happens and suddenly I have to stop what I’m doing to fix it,” or “why can’t the C# editor help me when I’m doing ‘bar’? I waste so much time doing it over and over again”. These can also include things related to exposing libraries for you to interface with as opposed to just features in VS that you interact with. If you wanted programmatic access, what would you like to see exposed?
Maybe I’ll be able to tell you: “Hey!! We added that in C# 2005.” Or maybe we’ll actually realize that what you’re talking about is a bug that we should fix before 2005 ships. But if it isn’t one of those then we will add it to the list of features to consider for the next version and you will have a chance to get what you want.
I wish that we had a better system for doing this rather than asking every so often on a blog. A public suggestion system would be ideal. Preferably with two way communication so that people would know that they were getting heard and that these features were being considered. But until we have that, I’ll have to do this the hard way.
If you think C# is perfect, then feel free to keep quiet. However, I certainly think that it could be improved immensely and I want to try to do it in a way that benefits all of you. I’d also like it so that in the future we had a much faster ship cycle. That way if you wanted a feature we’d be able to get it to you in 3-6 months. Currently we have a cycle that is multi-year. So we ship a product that is much improved across the board. But if we don’t have the feature you want then you’re not going to be getting it for another few years. Note: things like ship cycles are also things that you can request. If you want us shipping faster, let us know. Later on I’ll try to bring up the issues surrounding that. But if you do find that compelling, let us know!
Let me explain. No, there is too much. Let me sum up: let us know!