The 4 Main Factors in Knowing When to Refactor Your Code

If you are like most non-technical folks, “refactoring” usually comes up in product meetings and you nod your head in agreement but aren’t completely sure what the techies are talking about.  So let’s solve that here so you can not only contribute to these conversations moving forward but can also impress your friends at the next cocktail party (“have you ever thought about refactoring your mojito recipe?”).

Let’s start with the basics.  Refactoring means reorganizing your product’s source code into different components that are easier to maintain and work with.  The reason you need to do this is because when developers wrote the original source code, they didn’t factor in everything that they should have.  But let’s be clear: this isn’t your tech team’s fault as some things –like product roadmap, market needs, competitive pressures, the emergence of new technology and more – are constantly changing and evolving and thus many of the variables they should have considered in hindsight were unknowable at the time (unless Nostradamus was your lead dev).    So now with more knowledge, experience, and a better understanding of the domain and the solution, the tech team will need to rewrite portions of the code to “factor” all that knowledge in.

The timing of this refactoring, however, is often the tricky bit since it has to be balanced against the constant need to launch new features.  Management teams typically like spending limited bandwidth on forging new paths, not repaving roads that have already been built.

As a result, to refactor or not to refactor is an ongoing question that plagues the soul of many a programmer or product manager. To a coding perfectionist the answer is easy and it’s always a resounding “Yes! We must refactor.” But to the practically minded – aka to the teams with a mile long backlog of feature requests – the decision to refactor depends on if (and only if!) one or more of the following factors is in play:

1). Suspect Security

If the code base has ballooned to a point where it is not completely secure and can potentially be hacked, refactoring should be a top priority. A secure code base trumps all.

2). Buggy Code

If your product has reached a point where there are more bugs than lines of code, than refactoring is probably a good idea. Sometimes code becomes so complex and duct taped together that it’s better just to start over. But don’t confuse that with a situation where you have no automation testing: without auto tests it’s hard to determine if the code base is really bad or not. Thus, write the unit tests first and then evaluate.  (More on this in a separate blog post—automation testing can also be a hot topic at cocktail parties…)

3). Poor Performance

If your system can’t handle the current number of users and if clicks require the user to stare at the clock before pages render, the code should be refactored to handle more load.  Occasionally it’s just a matter of adding more server horsepower. But most of the time the code can be much more efficient.

4). Difficult to Maintain

The most common reason developers want to refactor the code is not because it’s too buggy or not secure, but because it’s too hard to maintain. In other words, it takes a lot of time and resources to make a change, and the code itself may not be aesthetically pleasing (yes even developers are artists in their own right). The rule of thumb for this type of refactoring is to only do it if the code base requires feature enhancements—that way you can pair refactoring with customer benefits and kill two (digital) birds with one stone.

So what’s your key takeaway?  Only refactor code if it can create direct product value: new features, fewer bugs, better performance, and/or higher security.  Never refactor code with the singular goal that it will be easier to maintain in some distant future, because that future could be way off — and way off base since you may even pivot once or twice along the way.

[Want to discuss this topic in more detail?  We’re here to help you refactor your thinking—ping us anytime at info@turnkey-labs.com!]