Refactoring - Refactoring HTML: Improving the Design of Existing Web Applications - page 22

Objections to Refactoring
It is not uncommon for people ranging from the CEO to managers to HTML grunts to object to the concept of
refactoring. The concern is expressed in many ways, but it usually amounts to this:
We don't have the time to waste on cleaning up the code. We have to get this feature
implemented now!
There are two possible responses to this comment. The first is that refactoring saves time in the long run. The
second is that you have more time than you think you do. Both are true.
Refactoring saves time in the long run, and often in the short run, because clean code is easier to fix and easier
to maintain. It is easier to build on bedrock than quicksand. It is much easier to find bugs in clean code than in
opaque code. In fact, when the source of a bug doesn't jump out at me, I usually begin to refactor until it does.
The process of refactoring changes both the code itself and my view of the code. Refactoring can move my eyes
into new places and allow me to see old code in ways I didn't see it before.
Of course, for maximum time savings, it's important to automate as much of the refactoring as possible. This is
why I'm going to emphasize tools such as Tidy and TagSoup, as well as simple, regular-expression-based
solutions. Although some refactorings require significant human effort—converting a site from tables to CSS
layouts, for example—many others can be done with the click of a button—converting a static page to well-
formed XHTML, for example. Many refactorings lay somewhere in between.
Less well recognized is that a lot more time is actually available for refactoring than most managers count on
their timesheets. Writing new code is difficult, and it requires large blocks of uninterrupted time. A typical
workday filled with e-mail, phone calls, meetings, smoking breaks, and so on sadly doesn't offer many long,
uninterrupted blocks in which developers can work.
By contrast, refactoring is not hard. It does not require large blocks of uninterrupted time. Sixty minutes of
refactoring done in six-minute increments at various times during the day has close to the same impact as one
60-minute block of refactoring. Sixty minutes of uninterrupted time is barely enough to even start to code,
though, and six-minute blocks are almost worthless for development.
It's also worth taking developers' moods into account. The simple truth is that you're more productive at some
times than at other times. Sometimes you can bang out hundreds of lines of code almost as fast as you can
type, and other times it's an effort to force your fingers to the keyboard. Sometimes you're in the zone,
completely focused on the task at hand. Other times you're distracted by an aching tooth, an upcoming client
meeting, and your weekend plans. Coding, design, and other complex tasks don't work well when you're
distracted, but refactoring isn't a complex task. It's an easy task. Refactoring enables you to get something
done and move forward, even when you're operating at significantly reduced efficiency.
Perhaps most important, I find that when I am operating at less than peak efficiency, refactoring enables me to
pick up speed and reach the zone. It's a way to dip a toe into the shallow end of the pool and acclimatize to the
temperature before plunging all the way in. Taking on a simple task such as refactoring allows me to mentally
move into the zone to work on more challenging, larger problems.