Names

From http://www.xkcd.com/

More about refactoring

Some points of disagreement with the critique against the Refactoring book found in this article about smells:

• Assuming that he is right in that most of us know how to refactor, I think that's because experience gave us the needed knowledge. Time and pain was needed. This time and pain, as in any knowledge area, can be reduced by reading books, like Fowler's.
  
  
• Apart from this, I think even a developer with experience and knowledge of most refactorings could miss some smells. We are humans and we acquire bad habits.
  
  
• A big part of the knowledge gained with experience is too intuitive and that brings some problems. When things are intuitive and you suddenly find someone that doesn't share your intuition you have to fight back with solid explicit arguments. Fowler's book helps you ease the work needed to find those arguments letting you show clearly why your intuition is the way it is. You can do it yourself of course, but it's easier to reuse the effort someone else did, if you share it of course.
  
  
• The book defines a vocabulary to deal with our intuition or implicit concepts, that is very very important. Now we can share it and we can communicate more efficiently. The same advantage we discovered after design patterns appeared.
  
  
• He agrees with Fowler that smells are important. The book is a reference to smells. IMO refactoring is more about identifying design problems (smells) than about the relatively simple things needed to make them disappear, but it's both of course.
  
  
• Things that are important, like smells, must be made explicit so the problem can be easily studied and possibly build some more knowledge on higher level concepts. One of those higher level concepts that could be further developed was the development philosophy of Continuous Design in which a core concept is refactoring.
  
  
• I think there's a confusion between simplicity and importance. Not only complicated books are important.
  

I think that a big reason for this disagreement comes from not seeing smells as thightly tied to refactoring as I see them.

More about architects

I found this great Fowler's article which I think compliments well with my previous post saying that architects are programmers.

Then I found this other great webpage he wrote about software design.
In the paragraph Do you wanna be an Architect when you grow up? he talks about this issue. I think that the I'm not just a mere programmer - I'm an architect feeling he points out is one of the reasons people feel so much against this natural unification of responsibilities.

Just imagine a football team in which only forwards are supposed to score goals and discouraged to assist and midfielders can only assist but are discouraged to score goals, it would be just stupid the way resources would be wasted with this separation.

Now imagine a software system in which only the architect takes architecture decisions and doesn't touch code, and programmers only code and don't take architecture decisions. It is unnatural.

Wouldn't be better if all players, err, programmers could make that decision as a team? You would just listen more carefully to the experienced programmer that is the architect and you'd have to be more trained on design. But that has always been your responsibility, you develop software! A programmer without design knowledge (or will to improve it) is like a football player that can't make a decent pass.

Finally it seems Jeremy D. Miller reads my mind with this post.

So I got quite surprised to discover so many similarities. I guess this architects are developers belief is more popular than I thought and that can only be good!

The meaning of refactoring

For a lot of people refactoring is not important. For some people this is because they don't know the correct meaning. They think it's just the name someone made up to describe simple code changes.
That's not refactoring.
You refactor when the changes you make improve the design while keeping its behaviour unchanged. Knowing when and how this improvement should be made is what is taught in the literature.

But there's another group of people that know the correct definition but still don't believe in it. This is because they measure their design quality just by its behaviour, so if the code already does what it's intended to do, they think it's good code. They believe in the "Don't touch the design if it's not broken" mantra (a slightly more valid reason to believe in this comes from lacking a good set of tests that act as a safety net for your design improvements).
For this reason they slowly start accumulating design debt. At some point, not too far in time, this unattended design improvement brings the impossibility to change code as it can't be controlled. This is because it's too difficult to understand and see all consequences of any change they may do, so either they don't change code anymore, or if they do, they start seeing bugs appear everywhere because they broke something they couldn't see it could get broken. So they say "You see? I was right, code shouldn't be changed if it's not broken", a self-fulfilling prophecy.

So in summary, refactoring requires the ability to systematically identify and improve problematic designs and it's important because it pays your design debt. This is necessary to understand and change your code easily.

This are great books you can read to improve your refactoring skills:

Refactoring: Improving the Design of Existing Code
Refactoring to Patterns
xUnit Test Patterns: Refactoring Test Code