The Visual C++ Weekly Vol. 1 Issue 24 (June 11, 2011)

  • What about the Code Snippets Manager that Visual C++, one of the ancient IDEs for C++, still not offer for us? We do need to use a SHAREWARE PLUGIN to be able to enjoy it. WTF is this???

    If you guys don't add it soon to VS, I swear I'm gonna create a FREEWARE and OPEN SOURCE plugin for VS2010 and share with everyone out there. And you know what's gonna happen with your Visual Assist X sales.

  • @WhyMSdontLikeCompetition?

    Last I checked, Visual Assist wasn't developed by Microsoft. So I doubt they'd complain if you released a competing tool.

  • I believe there are two points to consider here, WhyMSdontLikeCompetition. One is your call to include code snippets in your C++ projects. I contacted the IDE team to see what they have to say about that. They told me that we can’t comment right now on the new IDE features but keep checking back here because it’ll be on our blog first for sure.

    The second part is you perception that we would stop people from extending Visual Studio 2010. That's not just wrong: we strongly encourage you and anybody else, while we keep working in our roadmap, to close the gap for anything VS doesn't do today that you'd like to see. If you were also willing to share that achievement with the community, as a community program manager I am I'd see my dreams becoming real. Information about extending Visual Studio is available here -in fact, Visual Assist X is a product made by a 3rd party who saw there an opportunity to fill a spot we are not doing today).

  • Advance apologies for posting something that concerns VS itself, instead of VC++ Weekly..

    Diegum, you might remember me and other people raising an issue of the product quality issues with VS2010. The most important issues for me were in the area of the debugger (serious bugs with the basic functionality, eg, not showing the values of variables under certain frequent circumstances, can elaborate in detail) and the IDE (performance issues, can elaborate in detail as well). One of the most important things I and others were also picking up on was non-action or very slow action on bug reports, particularly on those submitted to Connect.

    You did recognize the above concerns and I believe tried to help escalate the issues that were being raised. However, that's not *nearly* enough.

    As an illustration:

    At one point you filed two of the issues I posted to this blog to show that VC2010 contains serious problems which SP1 does not fix, as bugs on Connect. This was in the end of January, this year. I expressed an opinion that this will do very little to help fix these bugs based on my prior experience with reporting bugs to Microsoft in general and Connect in particular. True, the reports will get closed some day and the underlying bugs will get fixed - to the extent it would take to make the problems in reports not reproduce any longer, but it will take so much time, that (a) it would be impossible to make sure that the bugs are *really* fixed, as with serious bugs this requires multiple iterations, and (b) the effect of the fixes would be negligible because by the time you publish them, the product will gain enough new bugs to counter that. Now, let's look at how things are going:

    The issues you filed are:

    connect.microsoft.com/.../watch-window-shows-structs-from-wrong-context

    connect.microsoft.com/.../odd-behavior-of-watch1-window-with-inheriting-structs

    You filed the issues in the end of January.

    Today, 6 months later, after VS2010 SP1:

    - both bugs are still with us, still plaguing our lives,

    - one of the bugs is marked as "fixed" despite there being no fix for public use (don't know if there is a fix for internal use inside Microsoft),

    - one of the bugs is marked as "closed" with a vague promise to improve the relevant area of the product and maybe fix the bug "over the next couple of product cycles".

    As we can see, I was right. The bugs continue to rampage. You (the development team) promise to maybe fix these bugs sometime later or claim that they are already fixed in some imaginary internal release, which we, ordinary customers, can't get our hands on. You ask us to report whatever bugs we find. Seeing as any reported bug will maybe get acted on in some minimum form only at least a year after the date it is reported, we, frankly, don't see why we should bother.

    Why not have a blog post about this?

    Why there are no updates to VS besides service packs, which are too rare, seem to be more about adding features, and invariably miss lots and lots of bugs / performance issues?

    Why it is taking you months to report on bug reports filed on Connect and *years* to actually do something about them?

    What are you planning to do about this? Do you see this as a serious problem or do you honestly think this is just a few dissatisfied customers talking on this blog?

  • @PleaseFixYourBugs It is a strange idea indeed that we should have to buy the next version of a product in order to see bug fixes.  It is rather more likely that I choose not to buy the next version because it will also contain bugs that will not be fixed until the following version.  Interesting business model to say the least.

  • @Chris:

    Absolutely.

    The main problem with fixing bugs the way the Visual Studio team does it is that bugs do NOT get fixed. Fixing complex issues requires several back-and-forth between developers and users, long turnaround times make this impossible. Proof: long-standing problems with IDE (perf) and Intellisense (perf, reliability). Users have been complaining about this since forever. The team is trying to change things, but all changes invariably end up as one step forward, one step back or worse.

    Sad.

  • what I find amusing/ironic is the countless calls for feedback, (recently, installing PerfWatson and configuring experimental toolbar layouts, as well as the constant "please report bugs to us" and "we take all feedback seriously"), coupled with what is practically a *guarantee* the feedback won't be used to improve the product on which we're providing feedback.

    It *might* find its way into improvements in vNext, or the one after that. But it kind of kills the motivation for providing feedback when you know that DevDiv has a policy of never actually improving a product once released.

    So in essence, it goes like this:

    - pay X thousand dollars to access Microsoft's developer tools

    - use your own time to give Microsoft feedback on said tool

    - wait Y years

    - pay Z thousand dollars to access this later version of Microsoft's developer tools, where your feedback may have had an effect.

    No matter how you look at it, that's just not a very tempting deal for the customer, is it?

  • I just saw this request - Let me follow up with the engineering team on these issues.

    Tony Goodhew

    Microsoft Corp

  • Any news or guidance as to when we could expect them?

  • The picture I see is this:

    A manager has been allocated to deal with dissatisfied customers. He was told beforehand that those complaints will not/should not be taken seriously, but in order to keep those customers as a customers not as a "have been" customers this manager is ordered to create an impression on those customers that company is really interested in their opinion, that company tries to do everything what's possible to make better product etc. etc. And of course always very polite, with smile on his face. We all saw this picture many times before.

    I myself do not believe that V.next will be in any way revolutional for C++ developers. (Copy this note and after release of VS2012 see if I was right)

    1. Yes, they will add some more features (but they will be half baked and full of bugs) but the only purpose of this step will be to keep our mouth shut. They will have an argument that will be always used if someone will complain about this or that "But we've added new features and didn't have time to do/fix X or Y".

    2. Old bugs will not be fixed, or will be fixed in a way that there will be buggy anyway.

    3. Ignorant attitude of those kids previously employed as a circus clowns/fish and chips workers on Connect will not change - you will get smart ass responses, and only after few exchanges with them when you actually prove them that they are wrong by saying that your code is incorrect and it should compile after all, they will resolve this as Won't Fix

    4. Every bug report will be resolved as either by design or Won't Fix or in best case deffered.

    5. Connect itself (speed wise) will be notoriously as slow as changes in VS for C++ programmers.

    I'm going to copy what I've just said here and after next release I will post it and we will be able to compare prediction with reality.

  • @Knowing me knowing you, a-ha:

    I see where you are coming from. Working with VS2010 can indeed be very frustrating, especially if you don't have an option of throwing it away and using a different tool due to internal policies. Seeing the IDE not being able to catch up to you while typing and taking tens of seconds or minutes to do simple things like text searches, and hitting the same bugs in crucial areas of the product over and over is not fun.

    I don't think the developers of VS have any malicious intents. I think they want to do good and fix all bugs. That said, they fail at this big time, and have failed for years. From the point of view of a C++ developer, the product is in shambles. One can theorize as to why this is, maybe someone up top thinks that the bugs affect only a small number of customers and thus they are not worth fixing, maybe the bugs are in areas that belong to more than one team and these teams pass the responsibility for these bugs around, maybe the developers just don't want to fix bugs because with the insane update schedule of one, at most two updates for VS a year, they simply can't do a good job at it, maybe there is something else in play, etc. Frankly, at this point, I don't care. It does not matter much that you intend to do good (fix bugs) if, in the end, you don't do it, whatever the reason.

    Similarly, while I don't think the developers will, for example, as you say in 1, add features only to have an excuse for not fixing bugs, I *do* think the end result will likely very well be the same as if they did just that. New features absolutely *will* be used as an excuse for not fixing bugs. (I actually have a big issue with this particular thing. The Microsoft folks are fond of saying "our resources are not infinite". I heard this so many times. Yes, we get it. We don't ask you to get infinite resources. We ask you to better allocate the resources you have. With respect to VS2010, who asked you to rewrite the IDE? Who asked you to rewrite Help? Not me, that's for sure. Yet you did both these things, spending a lot of your non-infinite resources on things that *you* wanted, not your customers wanted. Please don't use "our resource are not infinite" thing on me when you do that.)

    Sad times.

    Hopefully, Tony Goodhew brings some good news.

  • Hrrmph...

    Two weeks since my original post raising the issue of bugs that are not being fixed.

    Almost two weeks since Tony Goodhew told us he would take it up with the team.

    Any news?

  • Sorry for the delay on getting back to you on this.

    The reason for the delay is that the two issues you raised actually raised another issue on the interaction you've had with Connect. Let me address the Connect issue first before I comment on the bug.

    When you have a bug in the product and you report it to us through the Connect system we really only have a couple of ways of closing it in Connect. Unfortunately these flags don’t always express exactly what we’re trying to do and it doesn’t give you the correct expectation.

    We looked at changing this behavior late last year and because we were in the process of making changes to Connect we decided that we’d hold off on that. Your comment and discussion with Diego and the follow-up comments on the blogs here have told us that we really need to restart that work and get a better way of communicating with you on bugs/issues.

    I know these issues have been going on for far too long and I wish that wasn’t the case but what I would like to ask you is to give us a few months to work through BUILD and this issue and get back to you about what we’re thinking so you can give us your thoughts on the plan.

    As for the actual bugs that were raised let me explain where we are with those.

    The fundamental problem you’re seeing here is that the debugger uses an old hand written expression evaluator for C++ (I believe it is quite old, based on code that shipped with MS C++ 7.0 – You probably remember it, Programmers Workbench, 2 odd manual feet of documentation, etc). We’ve been fixing that and modifying it for years and with the upcoming Visual Studio vNext product we’re actually replacing it completely.

    This should solve a bunch of issues that you have and in fact the bug that was marked as ‘Closed’ was fixed by this change in the upcoming product.

    The other issue was marked ‘Deferred’ (this is an example of what I mentioned above – It’s actually marked ‘Resolved as Deferred’ which is the wrong thing to mark it as) is still an issue and you’ll see that in the next release.

    What is happening is that the expression evaluator in the debugger, while new and far better than previously, still isn’t a full-fledged compiler and thus cases like this are very hard to catch. The basic reason is that the expression evaluator can’t look at the same scope of universe that the compiler does for every expression due to the performance required to achieve that (if we did I’d imagine that we’d generate as many, if not more, complaints about debugger performance as we’d solve w.r.t this issue).

    So what we’re doing here is really to acknowledge that this is a bug and that right now we don’t believe the amount of effort to fix this issue and to address the resultant performance problems etc is justified in the context of the number of people impacted by this.

    Now this isn’t a good answer if you’re one of the people who are impacted by this but it’s the simple fact of having limited resources in terms of the size of the developer teams and the product schedules. Everyone faces these issues, you’ve probably worked on projects where you’ve said the words “Won’t fix” but we have to manage moving the whole product forward and addressing issues as best we can to appeal to the largest number of developers.

    That is just the pragmatic reality of software development unfortunately.

    If you have thoughts on how we can better communicate on these things with you, given the above, I’d love to hear them. You can reach me at my Microsoft.com alias, tgoodhew.

  • @Tony: I really don't want to get into what might seem as blind bashing here, but I'd like to add a quick comment to parts of your answer:

    "When you have a bug in the product and you report it to us through the Connect system we really only have a couple of ways of closing it in Connect. Unfortunately these flags don’t always express exactly what we’re trying to do and it doesn’t give you the correct expectation."

    -- that's completely irrelevant, and not our problem. You have chosen to use your own home-brewed (and ridiculously slow) Connect system instead of any of the dozens of existing bug-trackers. You have full control of it, and can freely extend, modify and improve it. If the current "close" reasons don't cover what you actually need, *get it fixed*. Don't tell your customers "we're sorry we give you absurd close messages".

    (And I realize you're not on the Connect team, but if it comes as a surprise to you, or them, that everyone hates Connect, both in terms of performance, usability and the interaction it allows, someone *really* needs to get their heads out of the sand, because it's a constant refrain *everywhere* the name "Connect" is mentioned.

    "with the upcoming Visual Studio vNext product we’re actually replacing it completely. "

    Wow. Really? That sounds great. (albeit, a long overdue move)

    "So what we’re doing here is really to acknowledge that this is a bug and that right now we don’t believe the amount of effort to fix this issue and to address the resultant performance problems etc is justified in the context of the number of people impacted by this."

    Wouldn't it be a bit more conventional to leave it open, then? It's still an issue that needs fixing, and should only be closed if 1) it has been fixed, or 2) a decision is made to *never* fix it ("won't fix"). For anything else, it is still an open issue as far as your customers are concerned.

    What you do with it internally is your own business (and perhaps Connect should allow you to set an "internal" status on the issue so you can mark it "deferred" internally, while customers see it as "open"), but as far as the customer-facing bug tracker is concerned, it is an open issue, and calling it anything else seems dishonest.

  • @Tony Goodhew:

    Thanks for the answer.

    I am grateful for the time you personally spend on this, but the result only highlights the issues and does not help a whole lot.

    You say one of the two bugs is going to be fixed in vNext and that the necessary change has already been implemented. Well, since we can't get our hands on the change in the form of a fix, there is really no way to tell that the bug is really fixed, *neither for us, nor for you*. Chances are, you fixed only a couple of the manifestations of the bug, and while technically you can say that the remaining manifestations are related to something else and so the bug is fixed, we will ultimately continue to experience the effects of the bug in vNext. With your update schedule, things like that happen all the time, so there is a good chance this will repeat here as well.

    You say the second bug is too difficult to fix and you are not ready to commit resources for fixing it, and that's just the pragmatic reality of software development. Well, OK, this is fine if one hears it once or twice per ten reported bugs, but we hear this much more often. So often that we can't help but wonder whether most of the time you say "too difficult" simply because you don't feel like fixing the bug, or whether you really have so much of technology debt and / or the product is really designed in such a bad way that the number of bugs that you can't really fix without rewriting the thing from scratch is so high. I don't know which is worse, frankly. If it is the former, the bugs are going to stay with us because you don't feel like fixing them. If it is the latter, the bugs are going to stay with us because although you'd like to fix them, you can't. And it has to be one or the other, because you say "won't fix", "our resources are very limited" and similar things all the time. Heck, you are talking about how you are going to rework Connect so that you have a better way to say "we acknowledge this bug, but we are not going to fix it just yet". You aren't talking about investing resources into fixing more bugs, you are talking about investing resources into making rejecting bugs as "won't fix" easier / prettier! That's saying something.

    In the end, the response on the first bug that we have been able to get is as good as we could get under the current rules, and that means that it is not good enough. The response on the second bug is the usual "won't fix, too difficult, you should understand" thing.

    And now for the main issue.

    Two of the bugs above are just an example that I have chosen primarily because it was Diegum who filed them using the information I supplied and not myself, so that we get the whole "non-reproducible, wrong / incomplete data" thing (which is also a big problem: you frequently wait a couple of months after the bug is filed without doing anything, then come out and yell "I can't reproduce this, please help me or I will close the bug", wait a day or two, then close the bug as "no repro" since, of course, whoever filed the bug has stopped monitoring it) out of the way. The real issue is that there are at least five, maybe ten, more bugs just with the debugger that we encounter regularly, but which we do not report, because the effort seems (and has been) pointless. There are also at least as many issues with the performance of the IDE, which we do not report for the same reasons. As bad as the responses for the two bugs above are, you have only scratched the top of the bug pool, and let me tell you, the pool is big. Harsh? Sorry, but, to paraphrase your words, that's the pragmatic reality that we, the users of your product, have to live with.

    As to your request:

    "If you have thoughts on how we can better communicate on these things with you, given the above, I’d love to hear them."

    Sure. Here is what I think you should do (no jests):

    1. Increase the rate of updates for Visual Studio. Aim for an update every 3 months, at the very, very least, with hotfixes between them. If you don't do it, the bugs will stay with us, I explained a number of times why.

    2. Double or triple the resources you allocate for fixing bugs. The product is in really bad shape. Commit to processing each new issue on Connect within two weeks, max. If an issue isn't closed after two weeks, close it automatically as "We have been too busy to respond". No jokes. This will make it readily apparent as to how much stuff you drop on the floor, and will help you stop doing that. Go over all existing issues for Visual Studio on Connect and close them.

    3. Likely the biggest thing. Stop wasting resources on reinventing things like Help (you aren't coming up with yet another Help system in vNext, are you? are you???). Stop! Noone needed the IDE to be rewritten in WPF! I am afraid to think what you are wasting your resources on right now as we talk. Sorry for being harsh, but this is the truth. You have a lot of resources, but you spend most of them on useless things. Stop doing this.

    This should help.

Page 1 of 2 (19 items) 12