Unless you're using something like .Net remoting (or the Java equivalent), and now suddenly everything breaks. Or you have a larger codebase split up into mult

Unless you're using something like .Net remoting (or the Java equivalent), and now suddenly everything breaks. Or you have a larger codebase split up into multiple .Net solutions and DLLs where code is referenced through the generated DLLs. The refactor looks great, until it starts breaking things for the many consumers of your code. In fact, the latter is a situation where simple text tools will make life a lot safer and easier than whatever the IDE does (which pretty much will be limited to the bounds of the .sln file, whereas a simple text tool operating over files in the entire codebase will alert you to the fact that this is being used elsewhere). My argument isn't to claim that simple text tools are better at refactoring. They aren't. However, I've run across several situations where we've had issues in a massive codebase because developers believed that refactoring was as easy as hitting the Refactor button in Visual Studio, and everything will work magically. The belief in programming 'magic' (whether through IDEs or frameworks that abstract a ton) without understanding what those tools actually do is what I'm worried about. Use IDEs to do what you need to by all means, but it's much better when you actually understand what it's doing before doing something with it.