Journal / 2016-12-03

Refactoring Software

I am heavily involved in refactors on a weekly basis; it’s the nature of software engineering. It’s probably the best and worst part about the field: There is nothing inherently costly about changing lines of code – just the time that it takes to make that happen. For me personally, it’s a constant struggle to weigh the pros and cons of refactoring. There is never going to be an ideal solution, and regardless of where the code ends up, it is impossible to predict all future requirements.

Some of the most successful refactors are baked into new feature work. It is easier to make an “excuse” to refactor code when it relates to something that is driven by product / business initiatives. It is important to tie refactoring to an explicit goal (i.e. time-based sprint commitment) – otherwise, the process of refactoring could become extremely vague and nondeterministic.

The biggest risk with refactoring is derived from poor planning in which unforeseen scope creeps in late in the game. If you are going to refactor something, it is imperative to have a clearly defined path in which the refactoring will take place.