Why refactor is the right business decision.
Tags: productivity, webdev, react
Published: 2020-08-27 22:03:01

The funniest thing just happened to me yesterday, my coworker introduced us to Recoil, a ReactJs experimental project. He said it was made by the React team to combat the short comings of Redux. Out of respect for the coworker, I started watching a 30 minutes video where the project lead introduced core concepts and motivations. Funnily, Recoil is based off the pub-sub pattern, which our current library choice, KnockoutJS, is also. The irony is that just a few days ago, our team lead wanted us to try redux precisely because pub-sub has become too chaotic for us. 

This is a trend in frontend development: to reinvent on the same idea over and over again. People are never satisfied with something created by others, which is kind of fair because my child will always be better than yours. Even during the question and answer section of the video, someone asked how is Recoil different from Mobx, another pub-sub library popular in the React community. The answer was that Recoil is built for React and can be compatible with other React features, such as concurrent mode. My best guess is that making mobx work with React features is too difficult. 

Despite being critical of this type of copying-and-calling-it-own behavior, I can see where it came from. At work we find it difficult to refactor and restructure our current app to uses react. The reason is that for each part restructured, we will have to put in a lot of time developing as well as testing. So the answer from up above was that we will just create a new app.

I think that is really the wrong mentality. Our previous coworkers were not idiots, especially the lead I had before, he was so smart that I can barely understand and improve the very minor shortcomings of his legacy; I felt enormous of accomplishment whenever I can. To recreate the app seems arrogant to me, it is an act implicitly saying that we can do better than the collective effort of predecessors. 

I believe this is really a problem of effort. Should we spend 1000 hours restructuring the app while not appearing any different or should we use the time to recreate the app and putting away all the baggages behind? This is a natural question that comes up, but it is a wrong one. What we are throwing away by recreating is not just past mistakes, but also a lot of past effort on improving, fixing bugs, testing, and scoping; all of which have to be re-done. It is not just developer time that are thrown away with the code, but also of QA engineers and product managers as well. We are throwing away a lot of progress for seemingly just laziness. The only exception may be if the product is straight up terrible and has bad reception. That is not the case here as our app is the only consumer-facing app that the whole company generate profit on. 

The decision was not in my control, especially since the pandemic prevented us from having the eye-to-eye conversation necessary when confronting a superior. However, I firmly believe that it is a wrong decision to start from fresh when the intention is to update internal working of the code, not the overall user experience and work flow. To be able to understand and refactor code correctly and safely is a core essential skill of a programmer. It means that the programmer has mastered all aspect of the code, from the language all the way to end effect. Therefore what is more precisely lost is not just the collective effort of predecessors, but also a precious opportunity for growth. Any student of 3 months can build an app, but it takes years of experience to refactor successfully in a timely manner.