Something that has recently struck me about the "little" refactorings implemented in the RefactoringBrowser and the focus of the research that has come out of UIUC. Those "little" refactorings are the arithmetic of program design. Kent espouses the idea of RefactorMercilessly, but usually we have trouble thinking of the large design change because of the difficulty in performing a large-scale transformation on our system.
However, if we learn to think in terms of the "atomic" refactorings, large redesigns are much less daunting. In high school math, they taught us how to solve problems like "What number divided by 6 is 3 less than itself." Initial attempts involve trial and error. Then they teach you to represent the problem as x/6=x-3. This doesn't really bring us any closer to the solution. BUT, then they taught us how to manipulate the equation with operations such as "Add the same number to both sides."
Now, solving the complicated problems now is easy because the manipulations are the terms in which I think. Whether you have a tool to perform the operations for you automatically or if you have to do the operations manually, does not make as much difference as the manner in which you think about the problem.
To be quite honest, I rarely think of refactoring code to achieve a particular GoF DesignPattern. Usually, the CodeSmells and I'm trying to alleviate the odor. After the fact, I can look at what I've done and identify it as one of the patterns. --DonRoberts

In my experience the patterns are over-kill and frequently violate "DoTheSimplestThingThatCouldPossiblyWork" and "YouArentGonnaNeedIt". The costs of not doing the simplest thing are twofold: (a) It takes longer to implement. (b) It takes other developers longer to figure out what is going on. Most of my refactorings (until now) have had the goal of making the code easier to understand. -- AsimJalis

*Note that, if you attempt to test the above in a programming language, you may get an inexact answer as a result of machine floating-point arithmetic. The true arithmetical answer is exact and correct.*
Floating point inaccuracy is an example of where computers have made us dumber. However, there are plenty of desk calculators with exact fractions that will have no trouble with this, including this one (http://www.mobilewikiserver.com/Fraction.html) and a couple that even solve the equation in your web browser:

In my experience the patterns are over-kill and frequently violate "DoTheSimplestThingThatCouldPossiblyWork" and "YouArentGonnaNeedIt". The costs of not doing the simplest thing are twofold: (a) It takes longer to implement. (b) It takes other developers longer to figure out what is going on. Most of my refactorings (until now) have had the goal of making the code easier to understand. -- AsimJalis

In other words, very small steps can get you all the way.X-3 = X/66(X-3) = 6X/66X - 18 = X5X - 18 = 05X = 18X = 18/5 or 3 3/518/5 - 3 = 18/5 - 15/5 = 3/518/5 * 1/6 = 18/30 = 3/5

http://icm.mcs.kent.edu/research/solvedemo.html(Type x/6 = x-3, x into the form)

http://www00.wolframalpha.com/input/?i=x%2F6%3Dx-3

View edit of June 17, 2009 or FindPage with title or text search