Now I know how dentists must feel when they’re drilling into the patient’s tooth and they hit a nerve. I think that previous to this I’d gotten at most, what, five or six comments? The refactoring item has 31 comments and counting. Whew.
First, let me say the comments about what refactoring tools are most useful are wonderful and will be passed along. They’re all great suggestions, and the team will be looking carefully at them as we think about what we’re doing in Whidbey. I can’t promise we’ll make everyone happy, but we’ll certainly try (as usual)!
Now on to the question of the name “refactoring”…
I think we should get one thing clear upfront: this has nothing to do with the perceived intelligence or sophistication (or lack thereof) of the average Visual Basic user. Every time I’ve ever had a chance to interact with living, breathing VB developers, I’ve come out of the encounter impressed as to how smart VB developers from all walks of life are. I’m sure we have our fair share of knuckle-draggers in the crowd, but, to be honest, this is the case for all computer languages – programming in C++ does not automatically make you intelligent any more than attending Yale University automatically makes you intelligent (both of these I can attest to first-hand). In my memory, there has never been a situation where anyone from the product team has ever talked about or discussed our customers with anything less than absolute respect. So although there certainly are quarters of this industry that do not treat VB developers with the regard that is due them, I can assure everyone here that they do not work for the Visual Basic team.
To put it even more bluntly: there is no question here of us thinking anyone is too “dumb” to understand anything.
Much of this brouhaha is really my fault in that I didn’t really explain what I meant when I said we “won’t be using the term ‘refactoring.’” I meant it really narrowly, but the way I wrote it I’m not surprised people interpreted it very broadly. All I was trying to say was that it is very likely that we will not be grouping IDE features that could be called “refactoring features” under a menu item that is entitled “Refactor” or “Refactoring.” That’s really it. We won’t have a menu item with the word “Refactor” in it. That’s all. We’re not going to be inventing new jargon to refer to the features, nor will we be hiding the fact that we support features that fall into the “refactoring” bucket. We just won’t have the menu item. (Actually, given the customizability of the VS IDE, you’ll probably be able to create the menu item if you prefer it.)
The VB team is not hostile to the concept of refactoring. Nor do we believe that all of our customers are unaware of the concept and/or have problems understanding it. It’s just that we felt we didn’t need to explicitly call out the fact that “Hey, the following features fall under the rubric of ‘refactoring.’” For example, symbolic rename is a feature that works pretty well on its own. We didn’t think we needed to explicitly link it to the abstract concept of refactoring to draw people’s attention to the feature or to convince them that it was useful.
The other reason I alluded to (and was, I suspect, the really sore point) is that for every developer who is immersed in the love that is refactoring, there are more than a few that aren’t. In fact, I’m one of them. I realize it may cost me some respect to admit this, but I’d never even heard of refactoring until C# added the feature to their IDE. I’ve never bought a copy of, much less read, Refactoring: Improving the Design of Existing Code. This does not mean that refactoring, as a way of life, does not have great merit or that I may not be woefully behind on an important trend in our industry. It just means that before C# added it, I didn’t happen to be familiar with the concept and, although I could be wrong here, I’m probably not the only one out there. (I’ll add that I like to think of myself as reasonably intelligent and well-informed, so obviously those two traits are not something I think are lacking in people who don’t know about refactoring.)
Given that there is some non-zero sized pool of developers out there who are not familiar with refactoring, the question then comes down to how to handle that. One way is to explicitly call out in the menu structure “Hey, these features fall into the category of ‘refactoring’ features.” and then rely on the user to say “Hmmm. ‘Refactoring.’ Never heard of it. I wonder what that is…” and start typing search terms into Google. A lot of developers, especially the professionals who are lucky enough to get to investigate new technology and new ideas as a part of their job, will do this. But there are a lot of developers out there who are going to say “Hmmmm. ‘Refactoring.’ Never heard of it. Crap, look at the time, I’ve got a lot to do before lunch…” and just move along. That’s because they don’t necessarily have the time or the extra available energy to spend exploring the nuances of Visual Studio, not because they are too stupid to figure it out. And, to be honest, for a lot of developers exploring interesting new trends in the computer programming industry is just not the main part of their job. They use VB or C# or C++ or whatever to get some part of their job done and move on. And if we can save them some time and energy by just saying “Here’s symbolic rename.” instead of saying “Here’s symbolic rename, but first I want to tell you about this little thing we like to call ‘refactoring’…”, then I think we’ve done them a favor, not treated them like idiots or children.
Now, if it was the case that helping out these developers would actually cost the rest of the developers something, then we’d have to really wrestle with the question. We do that kind of thing all the time, try and balance features between the different groups of developers that make up our customer base. But in this case, it really seemed like a no-brainer. If you know what refactoring is, you don’t need us to tell you that “symbolic rename” or “extract to method” are refactoring features. You already know that, we don’t need to drill it into your head. So, it’s not clear what harm there is in not having a “Refactoring” menu item as opposed to just showing the features directly.
Now, I realize that not everyone will agree with these sentiments, and that’s entirely OK. Despite the press we get, none of us at Microsoft really thinks we know it all. (Well, OK, maybe Don really does know it all, but he’s not always telling…) I think the feedback you’re all giving us on this issue is really great and we can continue this conversation as long as we need to. I hope this clarifies things a bit more, though.
I think you’ve just summarized, in a nutshell, why VB developers *in general* are looked down upon. If you think so lowly of them that (a) they don’t already know what "refactoring" is and (b) they aren’t interested enough to learn what it is, then why act shocked that people are up in arms?
I don’t really know who’s right or wrong in this issue. It’s probably one of those grey-areas that turn out to be a less-than-fruitful opinion war. I therefore don’t envy Paul’s job here, but I do thank him for opening himself up to this and similar issues through his blog.
What concerns me in this particular issue is an attitude displayed in some of the replies. There seems to be a line of thinking by some respondents that the users (developers in this case – yes we too are users) should be made to conform to the software (ie., thou shall understand the term "refactoring"), and not the other way around. This just seems to contradict a well established principle of software design.
Now maybe my summary of their intent is a little too simplistic, but even if it is partially correct, if this is how they think in the design of their own tools, I’d hate to think how they approach the design of applications for "real" users. 😉
You can also look at it this way:
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.
You’ve typed a long text here to explain why you won’t have a menu ‘Refactoring’. I wonder why you go 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 can google on the term, learn more, buy books about it etc.
Also: C# developers who have to work with VB.NET once in a while know where to find what and vice versa.
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 🙂
Pingback: Frans Bouma's blog
It’s not a question of whether or not the Visual Basic team thinks that VB developers are not bright enough to "get" refactoring, and I don’t recall seeing anyone suggest that it was. The issue is that by not using the agreed-upon standard term for the functions you’re talking about, you put VB developers at a disadvantage in discussing and using them, compared to their peers. What’s more, as I discussed in my blog (http://weblogs.asp.net/gad/posts/35384.aspx), consistency of experience in the IDE is another important reason for the VB team not to call refactoring by some other name. I use both Visual Basic and C# regularly, as I’m sure a significant number of other developers do. Why should I need to search for the refactoring features in VB.NET because they’re named something different from what they are in the C# IDE?
Unless there’s some compelling reason for the VB IDE to be differentiated (and I haven’t heard one yet), why not just call the set of features "refactoring" as in the C# IDE. Trust me that both VB and C# developers will thank you for the consistency.
I agree that having a whole menu dedicated to refactoring in the VB IDE seems awkward. VB devs are used to useful tools like this and they don’t have to be totally in our face and wasting that much real estate.
Pingback: Bill Evjen's Blog
I thought myself that having all the functions grouped under a menu item ‘refactoring’ seemed silly. Put them directly on the context menu as appropriate. If I highlight a single term in the code editor, why have to go through the refactor menu for symbolic rename? Put it directly on the context menu.
Pingback: Stefan Demetz
I appreciate that you’re taking the time to expose yourself to the ire of the Visual Basic community by attempting to explain why Refactoring will be implemented/exposed differently in VB 2005.
It is certainly arguable that exposing certain features outside of a ‘formal’ refactoring menu might make them more likely to be used – Symbolic Rename is probably the clearest example. Every programmer understands intelligent/safe renaming regardless of their understanding of, or interest in, the broader refactoring area – it can easily be understood as an extension to the existing Find & Replace functionality.
I don’t particularly care how the features are accessed – I just want to get as many of them as possible.
Refactoring is an extremely useful feature, but as a long time VB6 programmer I do regard Edit & Continue as more important, so I suppose you have your priorities right – especially since I can get a third party tool for refactoring if necessary.
Pingback: Panopticon Central
I think you’re right. There’s no need to label these features as refactoring tools. There may be some coders out there who have time allocated in their planning for refactoring. I’m glad I’m not one of them.
The activities currently known as refactoring used to be called programming. My vote is you introduce a "Programming" menu. Hey – even better – you could have a "Maintenance programming" menu!
Pingback: Panopticon Central
Pingback: Panopticon Central
The lion’s share of VB developers are neither interested nor educated on OO’s best practices, which leads to higher forms of OOD like patterns.
Refactoring deals mainly with architectures based on OOD and Patterns, so it is natural to assume the lion’s share of VB developers would not be interested in refactoring also.
I am a long-time VB developer who does use OO’s best practices including Patterns.
It is absolutely idiotic to even suggest that VB programmers don’t know what refactoring is. I’ve been a VB programmer for 10 years, I do read all the same books that C# and Smalltalk and Java people do -Design Patterns, refactoring, best practices and etc. I’ve known the word "refactoring" for at least 7 years now. Everybody I know that programs in an object oriented way, all my colleagues that I know of, know what refactoring is. Honestly, to even talk about this is stupid.
Everything that is in C# should be in VB as well.
Pingback: Panopticon Central
Lets face it gents …
writing in VB is easier .. some might phrase it ‘more approachable’ .. than Java and C# .. C# being a superset of Java. Therefore it makes a lot of sense to see if some of the uglier .. ‘more complicated’ .. features can be hidden from VBers. If at all possible they should be.
Additionally .. an honest survey of Java developers .. which has refactoring for some time now … would surely show that many .. I’d say most if not the overwhelming majority .. *never* use the refactring tools in the popular IDEs and are not sure how would be beneficial.
Anything that encourages refactoring in VB is a good thing. Period. Whether that is renaming it, hiding it or whateverer.