VB.NET developers, continued

The article I posted yesterday received the expected replies and I hope in the future it will show people how to look at software, the users of that software and on the various 'holy wars' that are still going on (and probably will be). Today

Paul Vick posted today an explanation why VB.NET will not have a Refactoring / Refactor menu, however it will have several features which will end up in the Refactoring / Refactor menu in C#. In short, he tries to explain why Microsoft made the decision to force VB.NET developers to use refactoring methods/functions but are not made familiar with the term. As I blogged yesterday that Microsoft is also to blame for the prejudice VB.NET developers have to face day in, day out, this is a good example of how Microsoft makes it hard for VB.NET developers to be seen as highly skilled developers. Below is the explanation for this, which I also posted as a comment to Paul's blog. I truly hope Paul Vick will reconsider their decision and will simply add the Refactoring / Refactor menu to the VB.NET IDE, so VB.NET developers who don't know the term will learn the term and discussions with other developers will show the VB.NET developer knows what he/she's talking about.

In a meeting C# developers, software architects and VB.NET developers are discussing the new product design. 2 groups understand the term 'Refactoring', it's a common IT/developer term. One group doesn't, because their IDE doesn't use it, or better: AVOIDS it to use it. Therefore, VB.NET developers can't participate in the discussion as equals, simply because they're never confronted with a general term in IT business however they're working with it every day. Not only does this hurt the quality of the discussion (you have to explain to them Refactoring is simply a term for a group of functions they already use), it also gives ammo to those who think VB.NET developers are less skilled and/or less smart.

Paul typed a long text to explain why Microsoft won't add a menu 'Refactoring'. I wonder why Paul went through all this trouble plus giving VB.NET developers a hard time in the future, while the opposite is much easier and will not give VB.NET developers a hard time: simply add the menu, add a simple explanation to the documentation what Refactoring is and you're set. VB.NET users who are not familiar with the term can google on the term, learn more, buy books about it etc., the same way as their C# counterparts will do when they open vs.net and see the term in the menu or read about it in the documentation. The C# developers will be able to discuss ways of develop software with java developers and system architects, even software development researchers on the university (e.g. researchers who look for methods to build better software faster, which resulted in methods like eXtreme Programming, which requires lots of refactoring). The VB.NET developer will not, because the terms used by the discussion partner are not familiar (in general) to the VB.NET developer, making the VB.NET developer look like a second grade developer.

I really don't understand why Microsoft puts in all this energy to explain a bad decision while the right decision is simple, appropriate and easy to explain. Fix it while you still can, I'd say :)


  • Let me add my vote too.

    MS fix it right...

    WORSE case, make the menu optional and allow VB'ers to enable it via the options. Don't make it completely unavailable.

    And don't make us have to hack a way to enable. You KNOW we will find a way to make it, or like functionality available. So instead of the standard, we'll have a bunch of custom written solutions (think XML comments in VB)...

    MS PLEASE don't make us go through this...

    Do it right, treat you VB.Net programmer like they are professionals...

  • I 100% agree. MS's job is to raise the lowest common denominator, not pander to it.

  • If I can ask, how exactly is implying that VB.NET developers require their IDE to teach them a term treating them like professionals?

  • Daniel:

    Not all terms of an industry should be known by everybody. However when you use a given set of tools and you don't know the correct name for these tools, you don't really know that you use them when you see/hear/participate in discussions about these tools. Also: all C# developers will be confronted with the term, will learn what it means. All VB.NET developers will not, and will thus not be forced to learn what it means.

  • I ment 'Will', typo. (I'm not a native English speaker).

    I also expect any developer to do a fair amount of learning but that's not the point. The point is that when you use a feature X, you should know hte feature you use is named X and not Y. As you can't know everything (a lot of C# developers will learn about refactoring whenthey open the IDE I'm sure), and when you DO use X, it is not more than appropriate the IDE, the documentation and examples/tutorials show you that the feature X is called X and not Y. That's the point.

  • My own experience is that many .Net developers don't know what refactoring really is, unless they also know what unit testing and design patterns are. It's not a language thing as far as I can see -- I have a client who is a VB.NET shop that, because their coders to test-first development using nUnit, can refactor code to their heart's content because a good suite of unit tests will tell you if you messed anything up in your refactoring.

    I also know tons of C# coders who don't write unit tests, so therefore any "refactoring" they do is essentially just mucking about with the code.


  • Don't worry, C# programmers aren't considered highly skilled developers either.

  • They can do whatever they want with VB.NET, I am long gone with C# and couldn't care less. That's what MS did with a die hard VB developer.

  • Interesting post.

    > it also gives ammo to those who think VB.NET developers are less skilled and/or less smart

    <humour americanSpelling="humor">

    I Once Knew A VB Developer Who Wrote So Much VB That He Started To Capitalise Each Word In His Emails.


Comments have been disabled for this content.