The Mindset

I was working on my book yesterday. I read one of the chapters I had written and I wasn’t happy with it. It wasn’t the grammar, nor was it the phrasing. It just didn’t feel right. Something in its flow was awkward, although I couldn’t just put my finger on it.

So I started working on it. I began reading it again, and changing the text as I go. Every couple of sentences I made some minor changes. At times, I deleted some sentences. With each such change I read the entire paragraph again to see if it makes sense. This process didn’t feel quite natural to me.

Then, toward the end of the second page, I came across a paragraph which seems to be perfect. I read it and really felt comfortable with it. The problem was it seems to be somewhat out of context. It belonged to the chapter I was editing, of course, but at its specific location it just didn’t make much sense. At this point, I began to feel that all these local/minor modification will not make a real difference to the quality of my text.

I knew what I had to do. I opened a new document and started writing. I knew exactly what I wanted to say. After all, I had written this chapter before. Everything was arranged perfectly in my head. But I wasn’t feeling limited by the existing text. I was free to do write whatever I want without constantly reevaluating it against the rest of the text. I wasn’t mentally bound to the structures and flow (or lack of it) of the original version of my text. I remembered the paragraph I was happy with. In fact, this was my trigger. I copied it to the new document and from that moment everything flowed…

Starting Over

The same applies to code. Sometimes focusing on “one step at a time refactoring” cannot make a real difference to the quality of the code. At least, it can’t make such a difference with a reasonable effort. In each refactoring step you do, you are still unconsciously bound to the big picture, which might be flawed as well. Sometimes you just have to start again with a clean sheet.

Does this mean you throw away everything you wrote? Of course not. You should focus on the a well-defined piece of the project, and you can of course keep segments which you feel comfortable with. But you don’t have to follow any refactoring pattern, or limit yourself to local-scope changes. Just use a clean sheet. The time it takes you to rewrite the code this time based on your experience and insights from the previous implementation will be significantly shorter.

This approach does not replace “one step at a time refactoring”. It is not optimal for all cases. No approach is. There are many cases in which small and local changes is just what your need. The best thing to do is to stay alert, and constantly evaluate the code. If you feel that small refactoring steps do not make you feel more comfortable with the code, don’t be afraid to take a more radical approach.

The Risk

There is some potential danger when you apply the clean sheet approach to code. Unlike my chapter rewriting, the code you write from scratch might not behave exactly as the original code. In that respect, small refactoring steps are safer. So, the clean sheet approach should be practiced with care. If the code you are about to rewrite is hidden behind a stable and testable interface, you can safely create a fresh implementation and verify its functionality.

As in many other cases, you have to consider the tradeoffs. On the one hand you have the benefit of starting with a clean sheet: writing code which is significantly better in shorter time. On the other hand there is the risk of practicing refactoring without the safety of small steps which can be verified incrementally.

This entry was posted on Tuesday, April 25th, 2006 at 2:30 pm and is filed under Design, Code Quality, Agile, Change, Refactoring. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.