If you want to know about the mechanics of refactoring there are quite a few resources out there. You can even find resources that outline refactoring strategy. But what about mindset? Is there a refactoring mindset that people should be aware of? I think that there is.

A while ago I was working with a team. We had time to refactor and we were all onboard with the effort. We wrote tests and tried to clarify the design. As we did we discovered things. It was like having everything come into focus. Once we had that focus — we leapt with it. That's when things started to fall apart.

Let me explain.

We had become so entranced by the direction the code was taking that we started to take bigger steps. Some weren’t supported by tests. I was aware that we were doing it, but I remained silent for a little while. We had some higher level tests and we knew were were going to backfill our work with more tests. I just said to myself “let’s see what happens.”

We went further. More refactoring. We were self-satisfied with the direction the code was taking. Then we ran our tests.

Failure.

Quizzical looks.

We went back and debugged. We found one problem and then another. We fixed them, but it was painful. We wrote more tests and finally after exhausting our ideas about what to test and looking at our coverage, we committed the code.

Now, the thing is, I’ve been refactoring for quite a while, so I sort of knew we were going to end up in a hole that we had to work our way out of. Why didn’t I stop it? The reason why was because I wanted to have a discussion about the way that we were approaching things, and that discussion is really most effective with a fresh experience. And, guess what? The discussion was not about testing.

We all know that automated testing is important, and nearly everyone who starts to do significant refactoring learns quickly that tests give you surety that is hard to find in any other way. But, knowing that testing is important doesn’t keep you from getting sidetracked. It’s good to think about the things that sidetrack you. In this case, it was the discussions we were having about the way that the code should be. You might be asking yourself — how could that be a problem? The reason is: if you are paying too much attention to the way that the code should be, you may not be paying enough attention to the way that it is, and the way that it is is important.

Code is the reality of a software system and unless we really know that reality, our changes can clash jarringly with the rest of the world. It might seem okay to say “well, we don’t care about the old behavior, we’re changing it to do something new,” but even then, it’s often better to know. It’s your baseline. The bridge between what we know and what we think we know can be wide.

I think the mindset of refactoring is important, and having that mindset not a chore — it’s just simple curiosity. Approach code like a mystery to understand. You’ll be surprised by what you find. When you look at code and reflect on the choices that you and others have made, it leads to deeper intuition about design.

There’s a world of possible insight out there.