Software Design/Modification Should be considered a "Set Based" process

When Matt Cherwin, the skilled DBA at my company first joined, one of the first and best pieces of advice that he gave me was to think of SQL as a "Set Based" process.  In other words, something in our discussion had indicated that I was thinking about the specific rows in a table, and his advice was given in response to that observation.

Immediately - SQL became much "easier" to think about, manage and generally work with.

I have found that this advice also applies to software development.  I find that it is much more powerful to think about the entire system (as a set) and to think about changes to the entire system (set).  This heavily takes advantage of code refactoring - where essentially every single last change that is made to the code is done as a formal "refactor".

In other words, I'm going to refactor the code to...

• Rename the method x.Foo() to x.Bar();
• Add method X to Y in order to facilitate Z.
• Add 5 new properties to class Foo.
• Allow Bar's to be deleted.
• Create 3 overloaded version of method X.Foo() that allow for...

The point is that any one of these changes might modify 1 line, or 10,000.  It should not matter to me as the one implementing the change.  I need to understand the implications of the code change - but I should not need to actually eyeball each change made by "the system".  

I should be able to simply indicate what I want done - and a refactoring tool should actually make the changes to the code.  The more changes that can be made "as a set", the fewer bugs there will be in the final product.

Define "Set Operation": Any operation that can be completed as a single, atomic change in the IDE.