Context

Why does refactoring get a bad name?  Because it's often used to describe three different things. "Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure.  It is a disciplined way to clean up code that minimizes the chances of introducing bugs.  In essence when you refactor you are improving the design of the code after it has been written.” (from Martin Fowler's Refactoring: Improving the Design of Existing Code.).

I want to thank Brad Appleton & Krzysiek Kosacki for some inspiration here (give me all the rap for the bad ideas though).

Twitter Blog

Developers complain that management doesn’t get refactoring.

I would suggest it is because the term has been used interchangeably for 3 types of refactoring.

What’s worse, one of these types shouldn’t really be necessary and it’s the one they use it for the most.

The three types of refactoring are: to simplify design, to fix design, and to extend design.

Simplifying refactorings are what you do right after you’ve got your code to pass tests & now know how to make it work better.

That is, you refactor your code to simplify it.

Refactorings for simplification right after going green is an extremely low cost way to reduce technical debt.

The tests are all there and don’t need changes.  The code is fresh in your head. Do it!

Refactorings to fix the design of code are what has ruined refactorings for the rest of us.

Refactorings to fix code design are refactoring to fix bad code that probably shouldn’t have been bad to begin with.

Note, we are talking about the design of the code - we're not talking about the functionality of the code.

Often this is required because people took short-cuts or didn’t know proper coding techniques (e.g., those exemplified by design patterns).

“We have to refactor” is the catch all phrase to clean up past evils. Is it any wonder management doesn’t like it?

They sense that if they let the development team do refactorings they will get no value back and are just rewarding bad behavior. They are not totally wrong.

There are rarely good reasons to write bad code.  Certainly not as often as it happens.

Refactorings for extending design are when the code is good, but new requirements require a different design.

In other words, your code is good, but the design is now insufficient.  Not because of a mistake, but because you need more (or less).

A powerful technique here is Refactor to the Open-Closed in our Essential Skills for the Agile Developer: A Guide to Better Programming and Design.

Also, see Avoiding Over and Under Design in the Emergent Design section in the online book: Agile Design and Effective Technical Agility: From Requirements to Deployment (this also has an example of Refactor to the Open-Closed).

So when you talk about refactoring, please be specific as to type: simplify design, fix design, and extend design.

BTW: I once talked to Martin Fowler about this, author of Refactoring: Improving the Design of Existing Code.

Essentially I commented that his book focused on fixing bad code but the refactorings could do the simplification and extension to design just as well.

His basic response was – “Yes, my book was long enough as it was.”  Totally understand!

As is this blog. Almost anyway.

If you found this blog of value you should check out the following:

• Design Patterns for Agile Developers public offering in Seattle 10/30-11/1
• Sustainable Test Driven Development
• Emergent Design

Alan ShallowayCEO, Net Objectives