Microsoft Tells What's Next for C++

Microsoft Tells What's Next for C++

  • Comments 64

 By chance,  are you among those who think that Microsoft is leaving native development in general and the C++ programming language in particular behind? You better watch this interview to Ale Contenti, Principal Development Manager with the Windows C++ team at Microsoft.

Click here to play this video

[Can't see the video player in this page? Try Channel9]

 

The interview was made by Christian Binder, Platform Strategy Manager with Microsoft Germany and Development Practices track owner in the still recent TechEd Europe 2010. Ale talks about key differentiators C++ offers today to developers, before other programming alternatives, but he also clears up any suspicion about Microsoft commitment to the language created by Bjarne Stroustrup by listing the efforts Redmond is doing for its evolution.

Ale had also delivered a session on ALM for C++ in that same conference.

  • Diego – I appreciate your answer although I doubt we’ll find a common ground on this one.

    About the Connect tool. The actual results justify its purpose, not the mere fact that it exists.

    Quick facts:

    Case 1. I reported once a bug for MS Outlook 2007. It broke a feature I was heavily using in Outlook 2003. I got the response that it will be fixed in the next major Office release (read Office 2010). Your internal case number  SRQ070622600669.

    Case 2. connect.microsoft.com/.../visual-studio-ide-does-not-resize-correctly-in-vista-x64 : "this issue does not currently meet the servicing/hotfix bar for this feature". Problem related to VS2008 just happens to not exist anymore no earlier than in VS 2010.

    Case 3. entlib.codeplex.com/.../26760 - Will probably be fixed in the new major version of EntLib, although the fix is simple and if you are using EntLib you will soon realize that it's not a low impact issue.

    There were more – all along the same lines. Once a Silverlight guy - I think – said that they were just on a tight schedule.

    Now, imagine a hypothetical situation that you spent a great deal of bucks and bought a new car. You realize that every time you turn on the windshields, they stop working after 5 minutes. You are really angry, because in the rain you don’t see a damn thing and to have the windshields back working, you need to restart your car. You go to car service and they tell you that they care about you a lot, but it’s by design, it’s not covered by warranty, doesn’t meet they servicing bar, but they will fix it in the new model that will come out in 3 years (they won’t grant it to you as a gift of course). Would you call yourself a happy car user? How would you feel if the same happened to the lights and A/C?

    When you say about fixing a bug (especially an annoying one) in some later SP or even a later major release (sounds like it doesn’t have to be the next one), I hear: “No time to fix the bug.”. If you had the time you’d fix, wouldn’t you? So it happens that I hear you prioritizing other things almost every time when I’m stuck with a problem in Microsoft’s software. Either you have too many bugs or too little resources to fix them. Software should work flawlessly, bugs should be fixed pronto subito. Period. Please don’t answer, ‘it’s unrealistic’, ‘we’re improving our dev process’ or ‘we’re sorry for the inconvenience’ – I’ve really heard it too many times.

    Thanks,

    Tadeusz

  • I love VS 2010. I don't know any other IDE which is so user friendly and good-looking. Especially debugger - nothing can compare with VS debugger in usability

  • Please fix some little things that have been skipped over..

    For example:

    Read through:

    connect.microsoft.com/.../msbuild-declares-microsoft-cppbuild-targets-as-invalid

    and listen to the simple request:

    "Maybe changing the wording of the error from 'This project' to the actual project name would help developers solve this a bit faster. "

  • @Diego:

    >Despite highlights and lowlights, the bottom line it that the Connect tool is the official mechanism to submit issues and suggestions, and everything we do in this team is based on input you guys entered there.

    Sadly, I think another bottom line is that every C++ developer I've ever discussed it with have had the same experience with Connect that Tadeusz described above:

    Bugs and feature requests get closed, closed and closed. Significant bugs that have been in the product since VS2k3 are still rotting in there. No one ever seems to say "I reported a bug on Connect, and they're actually going to fix it". Everyone is always saying "I reported a bug, it is a duplicate of 4 other bug reports, one from 2007, one from 2005 and one from 2004, and they're all closed because the team supposedly has no time to fix it".

    I'm sure you fix a lot of bugs, but you give your users the impression that you don't. You obviously have to prioritize which bugs you work on, but the impression you're giving your users is that the bugs *they* report get closed with "won't fix", and then the team runs off to play with something else.

    There's just very little incentive for reporting a bug on Connect when we know that "the last 7 bugs I reported got rejected with a "won't fix".

    For the tool to be useful, it has to give us the impression that our bug reports actually matter.

    Internally, of course you have to decide for a lot of bugs that "there's no time to fix it for the next release", and then treat them as closed. But externally, that's no reason to close the bug. I don't want to see the bug I reported get closed just because you don't have time to fix it in VS2k10. Close it if you *never* intend to fix it, or if you've already fixed it, or if there is nothing to fix.

    If it is simply a matter of "we don't have time right now", then don't show it to us as closed. Postponed, perhaps, but not closed. Or leave it open, and just take it off your internal list of outstanding issues for this release. As Tadeusz pointed out, we don't really care about your release schedule or your bug bar. All we care about is "has the issue been fixed yet? And if not, are they ever going to fix it". Closing the bug seems to answer "no" to both of these questions.

    I'm sure Connect allows you to generate all sorts of reports. Generate one showing the percentage of reports being closed as "won't fix". Then think about what message this is sending to the people who take time out of their schedule to help you by reporting bugs to you.

Page 5 of 5 (64 items) 12345