There was much handwringing last week when Somasegar announced what we already knew: VB.NET 2005 will not have refactoring. This resulted in a few emotional outbursts:
So if I have a tool that will automate things which should have no side effects unless I make a mistake, why wouldn’t I use it?
Sure, tools are good. But you have to discriminate between things that are easy to implement as add-ons-- witness the number of companies with refactoring tools-- and things that can’t be implemented this way. Again, why hasn’t any company released an Edit and Continue “add on”? Because they can’t. Let’s get our priorities straight.
It might be nice if people only work in one language, but as a consultant I’m working in both at about a 50-50 split. I don’t want to give up a large portion of my IDE experience/tools just because I change syntax.
I think it’s very unlikely that the MS-provided refactoring, if available in both VB.NET and C#, would work the same in both languages. Certainly they have a strong history of picking different approaches for each language, so I think your claim here is not supported.
THEY are the ones My is for. Same for EnC, and there was about the same level of backlash against the decision to include EnC in C#, just in the opposite direction.
Well, I don’t really care about the My.* namespace, but EC improves productivity for all developer skill levels:
http://www.codinghorror.com/blog/archives/000026.html
Unless you never generate runtime errors, I guess. 
And, like background compilation, EC a very low-level feature that has to be implemented by MS.
If you don’t like EC or background compilation, turn them off, don’t use them. And if I want refactoring, I’ll go buy it. I can’t “buy” EC or background compilation no matter how much money I have.
I like the Luddite reference. Did you know the Luddites were named for their leader, Ned Ludd?
I think “refactoring” is a bad description of the feature. All it really means [in eclipse anyway] is that when I rename or move a class any reference to it is changed. Eclipse will even do string representations for you if you’re using reflection, ect…
It’s very, very convenient and accurate. It is not crucial to getting things done. I certainly wouldn’t get emotional over an MS omission or delay. After WinFS, Edit and Continue and Refactoring I would be as weepy and confused as a cub scout in Neverland ranch.
I thought “refactoring” was getting rid of those numbers left over after long-division…
…And being a cub scout at Neverland ranch wasn’t so bad really…especially after the second trip to Mr. Jackson’s Special room.
sam: EC will be in both C# and VB.NET for VS.NET 2005… that’s been confirmed. Which is very nice.
But WinFS is definitely dead.
Jay Bazzuzi had a very interesting post on refactoring in Visual Studio. Their selections of which refactorings to include were based on making sure that they could make the code change with no side effects. So if I have a tool that will automate things which should have no side effects unless I make a mistake, why wouldn’t I use it?
And the whole reason I don’t want an add-on is that there is only 1 add-on I’ve found that works across languages. All the rest only work with one language or another. It might be nice if people only work in one language, but as a consultant I’m working in both at about a 50-50 split. I don’t want to give up a large portion of my IDE experience/tools just because I change syntax.
And the reason you see such a backlash against the My namespace is that most bloggers are more sophisticated developers than beginners. The beginner developers or the hobbyists don’t blog as much, and certainly not in our reading circles. 
THEY are the ones My is for. Same for EnC, and there was about the same level of backlash against the decision to include EnC in C#, just in the opposite direction.
As a person who is an advocate of advancement/change within the Software Development community, and takes a personal interest in IDE’s… I take offense to the Luddites reference:
Luddite Audio pronunciation of “Luddite” ( P ) Pronunciation Key (ldt)
n.
Any of a group of British workers who between 1811 and 1816 rioted and destroyed laborsaving textile machinery in the belief that such machinery would diminish employment.
One who opposes technical or technological change.
To relate my feelings to your Luddite reference… I say, by encouraging and desiring tools such as Refactorings we are in effect advocating the creation of “Textile Machinery” (laborsaving tools)… your implication that we are trying to destroy laborsaving tools… is simply ludicrous.
No one states that in order to write quality software you need Refactoring. No one argues that is not possible to get these features as add-ins either. The argument is that in many other popular IDE’s such as Eclipse, Refactoring tools are built in without the need to buy or download any addins.
Many of us are pushing for more advanced and labor saving features built into our IDE, that’s all.
To find out more about the importance of Refactoring:
http://martinfowler.com/articles/newMethodology.html
Hopefully this will give you an idea where many of us are coming from. I have read a lot about this topic where people seem to suggest that if a developer cannot design, architect, and implement software “correctly” the first time… then they are doing something wrong. That is simply a misunderstanding of Refactoring. One thing that I can accurately predict about large software applications is that the requirements are continuously changing. With these changes to requirements come changes to your code, even when you designed and implemented them according to specification. One way (the best I’ve seen so to date) of handling these frequent changes is to Refactor you code, the concept primarily popularized by Martin Fowlers book:
http://martinfowler.com/books.html#refactoring
Refactoring by the way is a big deal to many of us in the software development community and this is more of an issue about vendors listening to the desires of their customers, and releasing changes to them… not a debate over the most useful feature.
For another angle on my feelings I wrote a blog post of my own on this topic:
http://javakid.blogspot.com/2004/11/microsoft-lowers-bar-for-themselves.html
JavaKid
take offense to the Luddites reference:
It’s supposed to be funny. You can’t really use computers and be a Luddite.
Anyway. Refactoring support is nice to have, but this is about relative priorities to the people with low-level access to the language and the IDE (Microsoft).
You can buy umpteen different refactoring add-ins. It’s relatively simple to implement refactoring support in the IDE.
You cannot buy any edit and continue, or background compilation, add-ins.
It’s not sensible to prioritize the easy things over the hard things. If you want refactoring, you can buy it.
In a perfect world every feature would ship in the box, I guess. But I say let the third parties do what they do best, and let Microsoft do what they do best. Play to your strengths.
I guarantee that third parties will have refactoring add-ins that kick the snot out of what’s included in VS.NET 2005. Does anyone really doubt this?
Jeff,
Anyway. Refactoring support is nice to have, but …
A language like C# or VB.net is nice to have, but why use it when you can write assembler programs?
I’ve been long enough in this business to remember many people saying: “a GUI is nice to have, but it’s a toy and no user will pay for applications that look like comics.”
I even know some people arguing against IDE’s who still use notepad to write their code. It’s ok for them if they like so, but those people shouldn’t talk about what other developer need and need not.
You left out the other half of my sentence:
Anyway. Refactoring support is nice to have, but this is about relative priorities to the people with low-level access to the language and the IDE (Microsoft).
You and I could write a basic refactoring add-in in less than a day. Why exactly is this a priority for Microsoft?
You and I could write a basic refactoring add-in in less than a day.
If we could, why can’t Microsoft?
Jeff wrote:
Then Radi wrote:
Well i can tell you Randi, because idiots like Jeff who are not beyond the lying stage in their lives get to decide on what customers want and what the developers do.
It’s prety clear to me that Jeff has no clue what a developer does OR he is hired to lie to us about what are the reasons for decisions made OR he programmed a day on the product to and can not handle people critisizing HIS product…
Somehow i can not believe that microsoft can’t make resources available to give the customers what they want. I guess it was Jeff’s call to not ask for more resources and now he feels the floor dropping. Or maybe Jeff forgot to tell the decision makers that they needed to start up a new product so his team was not strained with refactoring. In that regard i guess Jeff might be a good developer but a BAD!!! project manager…
Jeff you made the VB.NET team look bad by not adressing the needs of the market and the lack of resources to your superiors!!!
Now quit giving excuses, yeah yeah we know for the price i buy VB.NET i can buy a plugin, so your decisions doubled the costs of VB.NET…
All we want is that you tell how important this feature is to the customers, when you do that instead of trying to divert attention to EC then we are friends again.
Now go!
Here’s the “official” Microsoft blessed refactoring add-in for VB.NET 2005:
a href="http://msdn.microsoft.com/vbasic/downloads/2005/tools/refactor/"http://msdn.microsoft.com/vbasic/downloads/2005/tools/refactor//a
So no more hand-wringing
Refactoring is one of the basics of software design. If we can’t get bullet proof support for refactoring in our software tools, then what hope is there?
In other industries we’ve advanced, we have car production lines for example.
However, for programming we are still stuck in the stone age, placing characters in a collection of files and crossing our fingers that it’ll work.
Our current IDE’s give little in the way of help via refactoring tools. They don’t inspire any confidence to use them. You could right a refactoring tool in one day, but it wouldn’t have the deep understanding of code that you require.
At Dynamic Aspects, a href="http://www.dynamicaspects.com"http://www.dynamicaspects.com/a , we’re trying to build a tool that will understand your code. There’s some demos available at a href="http://www.dynamicaspects.com/product/demo.asp"http://www.dynamicaspects.com/product/demo.asp/a .
" But they won’t help me decide how to refactor, or what the right semantics are for an abstraction, or predict in which ways the system will have to change in the next release. They won’t help me find the simple path among the complex, or choose just the right words to describe my thoughts, or understand the user’s problem better. They may help me be a more productive coder, but they won’t help me write better software."
This is exactly the reason why we need tool support, ideas can be tried out, you can describe your thoughts instantly in the code. Imagine if you had the confidence in your refactoring tool to allow you to try out ideas, moving responsibility between objects and methods with ease. Wouldn’t that make you into a truly productive developer?
“Ultimately, tools don’t make you a better developer. Experience does.”
Again, just an argument for allowing you to have the tool to express your experience. Any idiot can refactor some code, but only an experienced developer can refactor it into something sensible
Tools for brain dead programmers…
"Ultimately, tools don’t make you a better developer. Experience does. "
But would you want to write enterprise apps with nothing but a panel of toggle switches?
Tools can make you more productive. And for my employer, more productive = better.
Ultimately, tools don’t make you a better developer. Experience does.
If I had a ‘develop-better-than-Jeff’ tool I would be the better developer. Silly, of course. But, experience and tools are not mutually exclusive. The majority of your experience is how to use the tools properly and the tools help you gain experience with other things by making work easier.