Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News Explaining Refactoring to Management

Explaining Refactoring to Management

Leia em Português

This item in japanese


How can one justify refactoring to a CEO, and to other people with a non-technical background?

In a discussion with the topic "Refactoring Justification Language"Adam Sroaka, Agile Coach with BigVisible, said: “Refactoring is essential because requirements inevitably change and therefore code inevitably changes to satisfy them. When code which adheres to principles of good design is changed it may no longer adhere to those principles. Refactoring is a technique that allows us to improve the design of the code once we have changed it.”

Michael James, Certified Scrum Trainer with CollabNet, focused on refactoring while coding test first. He explained that our initial attempt to write new code is almost always a little bit messy so he and his pairing partner take the time to clean up.

Ron Jeffries, one of the XP founders, explains in a post entitled "Why is Refactoring a “Must”?" that given we can’t deliver all the infrastructure necessary for a Scrum Project in a two week sprint, we must be prepared to refactor in order to improve, otherwise we will end up with a mess that will slow our project team down. He also points out that a fundamental assumption of Scrum and any other Agile approach is that requirements will change. If the requirements change then the code needs to be refactored to clean up the loose ends that are left over.

On the same "Refactoring Justification Language" thread, Michael James added that even in a word of static requirements refactoring would still be required because we never write the code perfectly the first time.

Mark Woyna suggested we should look at the auto industry where every year manufacturers update their cars with many small changes only some of which are end user requirements. Sometimes they change a component to improve lifespan or reduce cost.

This reporter suggests that refactoring isn’t even something we should be talking about with management. It should just be a little part of our daily work ethic. First thing in the morning we do a rename or extract method just as a personal warm-up before moving onto other work.

Rate this Article