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 :)