One of the refactorings we're including in C# 2.0 is "reorder parameters." Strangely enough, it doesn't do what you think it might do. Wait... nevermind. It does exactly what you think it might do, it allows you to reorder the parameters in a signature. Any that calls that will then have their arguments reordered appropriately.

This is, of course, something you could do manually (all refactorings are), however it's potentially painful and possibly error prone. It's painful when you reorder parameters on a method that is called in 1000 places. It's potentially error prone in certain cases. Imagine the following:

class C {
     void Foo(int i, string s) { ... }
}
If we reorder the parameters of Foo, it's simple to recompile and just fix up everything that breaks. However, what if you have:
class C {
    void Foo(int i, int j) { ... }
}
If you reorder that you better make sure that you find all the places that call that and fix them up, otherwise you're going to have a bug. These types of reorderings are especially dangerous because after the reorderings your code continues to compile just fine.

A final example is the one I showed here at Tech-Ed. It's dear to me because it's something that bit me at one point. I started with the following code:

class BinaryNode {
     private BinaryNode left;
     private object value;
     private BinaryNode right;

     public BinaryNode(BinaryNode right, object value, BinaryNode left) {
           //initialize fields
     }
}
Now, at one point I realized that I wanted to reorder the left/right arguments to the constructor. I knew everything would still compile, so I did a find for all instances of "new.*BinaryNode" and fixed them up to call in the right order. However, i still ended up breaking something and it took quite a while to figure out what. Can you guess what it was?

The basic issue was that I had subclassed BinaryNode at one point and forgotten that I had a call to base(...) in the constructor. It was this sort of issue that using the re-order parameters helps you prevent. By using us we make sure that any code that calls the thing you're reordering will be fixed up for you.

If you have more than 5 things calling your constructor/method, do you want to manually fix them all up, ptentially making mistakes along the way? Or would you prefer something that goes ahead and does it all automatically for you. If it's the former, why? What do you prefer about manually modifying code. Are there issues with trust when it comes to modifying code? Do you want to actually see what's getting changed? I know I sometimes do. By going and fixing up every location I get a good feel for the code base. For example, by routinely traversing the code (even though it' painful), I can sometimes spot bugs, or opportunities for refactoring.