“Why do you have to reinvent everything?!” grouched my father, “We also used to Refactor, we just called it REWRITE!”.
Yep, as you can understand, I’m a second generation software engineer. Even though my father retired a long time ago, we still enjoy talking about our shared passion for software development.
I waited a moment, thinking about how to explain the difference, but all I could do was to repeat the mantra “Refactoring is the art of changing the internal structure of the code without changing its behavior. Rewrite, on the other hand, is when you write it from scratch.” I looked at my father’s face as he was thinking about my answer and I felt I could predict his reply. He is about to say “Well, this Refactoring practice sounds exactly like Rewrite to me. The essence of rewrite is changing the internal structure while keeping the behavior”. I was right, that was his exact answer.
“OK, OK,” I said “let me try again, I think I have a better explanation. Refactoring is like playing a game. I call this game Customer is In the Room.” “I’m listening,” he said, and I continued: “When I refactor, a customer or any other stakeholder can always, at any point in time, challenge me to run the software and I will be able to run the current version I’m working on without any delays. With rewrite, you can’t do that. You will only be able to run the software when you are done rewriting the unit. That’s a big difference!”
“Right,” he said “When I rewrite I can only run the software when I’m done. Though, how exactly do you accomplish that? And what do you mean by ‘without any delay’ don’t you need at least a few hours for stabilization and taking care of any loose edges, before you can run it?”
I explained, “I do that by composing the change as a sequence of micro-steps called transformations. Each transformation is a tiny change to the code’s structure that is promised to keep the behavior intact. Since each such refactoring transformation takes no more than a few seconds, my software is always valid and I can always run my latest ‘under-development’ version.”
“I got the idea” he said. “I think I understand how it may work. I just don’t understand why would you choose to work like that. Breaking the change into such tiny steps seem so inefficient. There must be a price in time or resources you pay with this approach!”.
“The contrary.” I replied. “If there is something I learned about software development in the last 20 years it is that the smaller the steps you take, the faster and safer the progress is! Most IDEs today support refactoring by offering a wide range of automated refactoring transformations. To my experience, when I refactor, I go faster and safer than rewrite.”
“There is even more to that, when I refactor I can check-in and integrate at any point in time, not just at the end as it is with rewrite. As a result, I avoid the pain and defects we usually have to face when trying to integrate a big change and finding out that the code base was meanwhile changed by other team members. That’s a huge gain!“
“Sounds very interesting” he answered. “Though is seems too late for me to acquire this skill. It looks like it takes a lot of practice.”
“I can teach you” I said, happy about the opportunity to offer him to pair with me. “You’re right, it takes time to practice, Join me, I’ll be happy to show you how it’s done.”
Want to learn more about refactoring? Join us for a refactoring Code Kata or subscribe to our Youtube channel.