Joe Poon

While working on a piece of code, we’ve all come across the situation where we feel that the code should be refactored because in the back of our minds, we know that the code will soon need to do more. The conversation with your pair may go something like this - “..the system will eventually need to do XYZ and since we’re dabbling in the area, let’s refactor the code such that it is easier to incorporate feature XYZ in the future…”

At first, it may seem that to code with such foresight is not only courteous to your teammates but downright responsible programming. Moreover, the programmer in us loves to massage and improve code. However, despite these good intentions, premature refactoring of code can be a dangerous trap.

One of the problems of premature code restructuring is that it convolutes the intent and introduces complexities into the code base before they are truly necessary. Symptoms of up-front design begin to creep in, code is abstracted in overly generic and complex ways. Furthermore, we all know that like the weather, requirements change. When change happens, we sadly discover that the premature refactoring of code in anticipation of that no longer imminent feature was done under wrong assumptions and motivations. Our prefactored code has suddenly become obsolete before it was given a chance to shine.

Refactoring is improving the design of existing code and an incredibly worthtwhile practice. Perhaps prefactoring (premature refactoring) could be refactoring’s untimely evil cousin, improving the design in anticipation of non-existent code.