š Rating ā 5 (2 votes)
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:
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.
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ā¦)
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.
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{a}turnkeystaffing.com!]
TurnKey Staffing provides information for general guidance only and does not offer legal, tax, or accounting advice. We encourage you to consult with professional advisors before making any decision or taking any action that may affect your business or legal rights.
Tailor made solutions built around your needs
Get handpicked, hyper talented developers that are always a perfect fit.
Letās talkPlease rate this article to help our team improve our content.
Here are recent articles about other exciting tech topics!