Twitter Blog on Refactoring

September 10, 2012 — Posted by Al Shalloway

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:

Alan Shalloway
CEO, Net Objectives

Subscribe to our blog Net Objectives Thoughts Blog

Share this:

About the author | Al Shalloway

Al Shalloway is the founder and CEO of Net Objectives. With 45 years of experience, Al is an industry thought leader in Lean, Kanban, product portfolio management, Scrum and agile design. He helps companies transition to Lean and Agile methods enterprise-wide as well teaches courses in these areas.



        

Blog Authors

Al Shalloway
Business, Operations, Process, Sales, Agile Design and Patterns, Personal Development, Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Cory Foy
Change Management, Innovation Games, Team Agility, Transitioning to Agile
Guy Beaver
Business and Strategy Development, Executive Management, Management, Operations, DevOps, Planning/Estimation, Change Management, Lean Implementation, Transitioning to Agile, Lean-Agile, Lean, SAFe, Kanban, Scrum
Israel Gat
Business and Strategy Development, DevOps, Lean Implementation, Agile, Lean, Kanban, Scrum
Jim Trott
Business and Strategy Development, Analysis and Design Methods, Change Management, Knowledge Management, Lean Implementation, Team Agility, Transitioning to Agile, Workflow, Technical Writing, Certifications, Coaching, Mentoring, Online Training, Professional Development, Agile, Lean-Agile, SAFe, Kanban
Ken Pugh
Agile Design and Patterns, Software Design, Design Patterns, C++, C#, Java, Technical Writing, TDD, ATDD, Certifications, Coaching, Mentoring, Professional Development, Agile, Lean-Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Marc Danziger
Business and Strategy Development, Change Management, Team Agility, Online Communities, Promotional Initiatives, Sales and Marketing Collateral
Max Guernsey
Analysis and Design Methods, Planning/Estimation, Database Agility, Design Patterns, TDD, TDD Databases, ATDD, Lean-Agile, Scrum
Scott Bain
Analysis and Design Methods, Agile Design and Patterns, Software Design, Design Patterns, Technical Writing, TDD, Coaching, Mentoring, Online Training, Professional Development, Agile
Steve Thomas
Business and Strategy Development, Change Management, Lean Implementation, Team Agility, Transitioning to Agile
Tom Grant
Business and Strategy Development, Executive Management, Management, DevOps, Analyst, Analysis and Design Methods, Planning/Estimation, Innovation Games, Lean Implementation, Agile, Lean-Agile, Lean, Kanban