I’d be a millionaire if I had a dime for every time I heard someone say, “We need to refactor the code before implementing this feature.” However, sometimes I struggled to understand why refactoring was so important and how to deal with it.
Despite having a technical background, refactoring troubled me because:
Have you ever stumbled upon this yourself?
Keep reading to learn more about what refactoring is, why it matters, when you should refactor, and techniques you can use to implement it within your product team.
If you work with digital products, you probably hear the term refactoring.
Refactoring involves improving the quality of the code base while preserving its current functionalities. This creates a more maintainable, scalable, and robust code.
You may wonder why software engineers don’t just build the code base right from the beginning. In general, development teams take one of two approaches:
From my experience, software engineers push for the first, while product managers push for the second. To help you decide, ask the following questions:
The more confident you are, the more you can build from the beginning. Sadly, that’s seldom the case. More often than not, you’ll need to refactor code.
To help you better understand refactoring, I have an example of a failed and a successful attempt.
I worked for a digital marketplace, and customers complained that uploading new products took too long. The reason was simple:
The problem was critical, and we had to act.
A senior software engineer asked me to let him refactor the code during the rest of the week. I agreed with him. As the week finished, he was confident that we could put it live. We set the following Monday as our release date.
The refactoring went live on Monday at 7am, and the image processing time became 150 times faster. That was awesome. I couldn’t believe it. We were so happy I invited the software engineer for a delicious breakfast.
The marketplace director awaited us when we returned to the office at 08:37. His face was anything but friendly as he said, “David, fix whatever you guys did. We’re missing 50K products in our shop.”
That was it. An unexpected effect of refactoring occurred. It caused a conflict with the shop importer, resulting in the removal of products from our catalog. Why did we get there?
It was painful, but it taught me a lot.
Another time, at the end of the month, we issued invoices to all partners. We had to change a few details to make it more transparent. When I brought this to the team, my software engineers said they wouldn’t do it without refactoring. The reason was simple: the code was complex, unscalable, and outdated.
I agreed with them on refactoring. To ensure success the tech lead:
The team needed a whole week to refactor it. By the end of it, we learned:
After evaluating the results, we invested another day to cover the remaining edge cases. That resulted in simpler and more maintainable code, which allowed us to add changes in a few days instead of weeks.
Knowing when to refactor is as crucial as doing the refactoring itself. Good refactoring leads to:
Before you start refactoring you need to make sure you have:
But when should you refactor? When you observe the following, it’s time to consider a refactor:
Once you decide to refactor, you can benefit from a few techniques:
When you choose to refactor your code, it’s still usable, up-to-date, and relevant, but you need to make it simple to understand and more maintainable. Yet, sometimes, refactoring wouldn’t be the best choice. Reflect on the following:
The more your answers skew to the right, the more you’d benefit from rewriting the code.
Rewriting means throwing away the current code version because it’s no longer maintainable or scalable. It implies redoing everything the previous code provided in a new way. However, consider this approach a last resort because it’s time-consuming and brings risks of unexpected side effects.
Code rarely starts perfect, so it needs to evolve according to the value it creates for your customers and business. When the time arrives, refactoring helps you keep your code base simple, scalable, and maintainable.
That said, refactoring requires preparation to avoid undesired side effects. You might consider rewriting as an alternative, if refactoring requires more work than writing the code from scratch. Remember, always maintain an open dialog about when to refactor and when not to.
Featured image source: IconScout
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
To proactively address liability concerns, you can create an internal product recall team for dealing with risks and ensuring quality.
Our Galileo AI Fall ’24 release makes Highlights available to all Pro and Enterprise customers. We’re also debuting Ask Galileo, which enables you to directly ask questions about what you see in session replays.
Mark Kamyszek, Vice President of Product Management at TeamSnap, talks about the product launch process for B2B2C companies.
Continuously switching between various tasks and activities strains cognitive resources and leads to feelings of fatigue and overwhelm.