choong pw

I believe this will be a controversial topic to most engineering managers or stakeholders. Nevertheless, having to experience different forms of refactoring in code and process, I like to share some of my thought here.

Remove unwanted/redundant code and feature

Let’s admit. Most of us as software engineers is a perfectionist. We just can’t stand messy/spaghetti code. And believe me, most of the time this kind of code is not well maintained. Too much tech debt and dead code that no one knows the purpose of its existence. To make things worst, some of the unit tests or functions may be obsolete, but we still try our best to keep them.

If its ain’t broken, don’t fix it.

This exercise is good in a way that we force the team and the Product Manager to look back and map out all the important features. And then put more attention to the most used feature to make it works better. The benefit of this, the team already has the experience of what the user wants, and this makes it easier to make the decision.

Reduce tech debt

For most of the initial version of the application, we hack our way through it. A nicer term is called “Growth Hack”. Often, this will bite back with technical debts that are not as straightforward as you think to fix it. An example would be architecture decisions that were made during the initial design.

You’ll start to realize that it is getting harder to implement new features to the existing application. No one is to blame, as we believe in the good intention of the original creator making the best choice at the given moment. The requirement or use case may have changed, and the initial design is not optimal anymore.

If the knowledge transfer wasn’t done properly. We can’t expect any random new hire to be daring enough to do a major overhaul to the system too, right?

Developer knowledge

This brings us to the next point. It helps the team to understand the whole system inside-out. I always would encourage junior or new joiners to experience working on a refactoring project at least once. Refactoring the whole application may be too far-fetched, they should at least try to refactor some of the key features within the application.

The process of picking up the knowledge is faster compared to fixing from ticket-to-ticket. Most importantly, they are able to work more efficiently after the exercise as they understand the whole application better. Not just on handling support and bug, but also adding new features to the existing application.

Refreshing the system

I believe till today, you still see web-application where their UI looks outdated right? Along with doing the refactoring, we also can make use of this opportunity to relook at the UI/UX experience of the app.

As an example, adding the support for mobile layout. Or, splitting the architecture to frontend and backend. With more focus areas of work and responsibility, is much easier to think about delegating work and scaling the application.

Save cost

This might be another wildcard point and is also part of the reason to write about this topic. Often time, you see engineers spinning up unintended services for testing or one-time use. Again, assumed good intention from the team. We just tend to forget to remove it.

Refactoring will force the team to relook at some of the underused services. Be it using third-party services or self-hosted cloud resources. Either way, we can save tons of dollars.

When not to refactor?

At the end of the day, we need to weigh in the options before we take on this massive exercise that will take a lot of resources out of the team. If the long-term benefit is worth the effort, it is very rewarding as you can see the team performance improve very rapidly from that onward.

To start, if you don’t have a well-documented strategy of what to refactor and how to transition/migrate during the refactoring process. Don’t do it. Spend the time to work that out and communicate it with the team and stakeholders first. Also, some older technology is just not that friendly to migrate. (take a look, till today you still see COBOL is most of the banking system)

If you don’t get the buy-in from businesses and stakeholders. This is reality. Anything that the team wants to work on, somebody needs to pay for it. So, start to socialize the idea and convince the long-term benefit to them before committing to it.

If your team member is fresh and new, don’t even think about it. Refactoring requires strong product and domain knowledge in order to execute them. If they don’t understand the product well enough, how confident are you at the changes are significant enough to bring positive impact? Btw, I am talking about multiplier impact work.