Stop Thinking During Refactoring

| by Vikas Hazrati on Oct 20, 2011. Estimated reading time: 2 minutes |

Refactoring is a technique for changing the internal structure of the program without changing its external behavior. On the face of it, refactoring seems to involve a good amount of thinking, however, too much thinking could be detrimental as well.

Kent Beck suggested that one of the challenges of refactoring is succession which means how to divide the work into safe steps and how to order those steps. Moving too quickly on refactorings may result in getting burnt with unstable code. On the other hand, thinking too much and taking safe steps might slow down the process considerably.

As many of my pair programming partners could tell you, I have the annoying habit of saying “Stop thinking” during refactoring. I’ve always known this isn’t exactly what I meant, because I can’t mean it literally, but I’ve never had a better explanation of what I meant until now.

Kent explained the concept of 'horizontal and vertical refactoring'. Vertical refactoring would involve situations like moving the method or field up or down a call stack whereas, horizontal would involve doing a similar kind of refactoring across a bunch of siblings. According to Kent, one should not cross between either kinds when refactoring. 

When you have multiple callers to refactor or multiple implementors to refactor, it’s time to begin paying attention to going back and forth between vertical and horizontal, keeping the two separate, and staying aware of how deep to push the vertical refactorings.

But doing this is not easy...

One thing which has been particularly helpful is index cards.

Keeping an index card next to my computer helps me stay focused. When I see the opportunity for a vertical refactoring in the midst of a horizontal phase (or vice versa) I jot the idea down on the card and get back to what I was doing. This allows me to efficiently finish one job before moving onto the next, while at the same time not losing any good ideas. At its best, this process feels like meditation, where you stay aware of your breath and don’t get caught in the spiral of your own thoughts.

J. B. Rainsberger agreed and mentioned,

Whatever you’re working on, when you want to focus, have a card and pen handy. When something pops into your head that you don’t absolutely have to do right freaking now, write it down in 5 words or less, then get back to what you were doing. It works wonders.

This is quite similar in principle to the narrow change approach suggested by Joshua Kerievsky. Here, focus is limited to a small number of change points at a time and then using this information the next narrow change or a parallel change can be picked up for refactoring.

Though refactoring involves thinking, however, keeping the focus and letting go the the temptation to go on a tangent is essential for healthy refactoring. As Kent put it,

Half way through my partner started getting good ideas about how to move some of the functionality to B. That’s when I told him to stop thinking. I don’t actually want him to stop thinking, I just wanted him to stay focused on what we were doing. There’s no sense pounding a piton in half way then stopping because you see where you want to pound the next one in.

Rate this Article


Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Why does this apply only to code refactoring? by Roopesh Shenoy

This applies to pretty much anything, especially but not limited to software development. Focus on one task at a time, jot down any brilliant ideas you get on a piece of paper so that don't switch till your current task is done - it's so effective that this should be taught to people in school if you ask me.

Same applies to switching off cell phone, responding to mails only on a predetermined schedule, and so many other productivity boosting habits.

Say: "Focus." & "Do one thing at a time." by Jeff Grigg

If you told me to "stop thinking," I would immediately stop working and demand and explanation as to what you meant. And if you kept saying it without explaining, I would use strong language and get unpleasant.

And that's quite extreme behavior for me.

Focus on the positive. If you want people to focus on one thing and get it done before starting the next one, then say so. Strive to be articulate.

Analysis paralysis.... by David Zaffery

While I understand the intention of your article, advocating folks to "Stop Thinking" is just not smart. What you are really trying to avert is feature creep. Having a clear plan of what and why your doing something is all that is required. Use first principles when thinking through designs and write appropriate tests to maintain your development plan. Done.

Nice idea, but here's another take. by Assaf Stone

My take on refactoring is usually quite mechanistic. Roughly 90% of my refactorings are correcting violations of the DRY principle. I also use a static code analysis tool to detect repetitious code. Given these two, I do very little thinking about refactoring. I simply make sure to fix violations by extracting methods and classes, based on who and where the code's clients are.

Hence, to me, "Stop thinking" means simply - don't over-think the matter. Just do it! (where "it" means refactor to remove repetitions).

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

4 Discuss