There are generally very few situations where you have a single method from a single class sprinkled across an entire codebase for a good reason. That always indicates high coupling and design problems. There are even fewer reasons to rename a well designed method. Constant renaming and high-coupling are bad habits that seem to be commonplace when working in strictly static languages and yet they are known to be bad habits even there. At least dynamic languages discourage these anti-patterns. Not to belittle your friend, I found myself falling into these traps constantly when working in C#.
Honestly, what I'm saying is that these problems just are not nearly as significant in say, Ruby, as they are often made out to be by static typing proponents. It's a bit disingenuous to point to these trivialities as reasons why static > dynamic. If it were true then there would be little benefit in dynamic languages. Clearly there is.
More generally, the ability of modern IDEs to manipulate code structurally, and not just texturally, has been eye opening for me.
The theory that you can get good design up front depends on having both a stable problem and a stable solution. Most places don't have stable solutions, because creation of software is usually an exploration of the solution space. (If you don't need to explore the solution space, that often means you should just buy something off the shelf.) Quite a number don't have stable problems, either. Some people have innovative competitors; others are doing startup-ish things.
As Keynes said, "When the facts change, I change my mind. What do you do, sir?" I think that applies to design as well, method names included.
I am reserving most of my replies for the comment section of my own blog, but I couldn't resist say hi to you. I am in fact sick of typing in type labels (so strong type inference is great, it is just finally becoming available to us masses).
Also I would like try defend refactoring. Those that don't think it is important have not seen it used well (there are a lot of trivial uses of refactoring). I remember pair programming with Brian Slesinsky (when the two of you were coaching). We wanted to change some deep functionality of the project. Brian slowed the moment down for a bit and then said something like: "we call this refactor method, then introduce this error here, fix it here and then call this last refactor to clean it up." He was definitely not only doing what the IDE supplied but thinking in a very deep way how to trick the IDE into correctly performing a big change it was not designed for.
I don't think you should post it here if you aren't prepared to discuss it here. That seems disrespectful to the community.
For example, I'd like to hear your response to this objection: http://news.ycombinator.com/item?id=3633596.
Yet it seems to be what the evidence is telling us.
What makes you say that?
First, I happen to have worked with this fellow before [Hi, John! Long time no see. Fun to come across your post here.] and I'm sure he's quite sincere.
Second, having spent a bunch of time lately in dynamic languages (Ruby and JS mostly), I do indeed miss the automated refactoring tools that existed for Java. It's really nice to be able to rename a method everywhere across the code base without worrying that something else got mangled. I also miss the magic documentation that a type-aware IDE can provide; I spend a lot more time digging through layers of code to figure out what a particular parameter is expected to be.
Not that I want to switch back; I agree that a language with strong type inference is the way to go. But man, I miss the tools.