To refactor or to keep going
Published on 2020-09-15 20:36
In my professional life and now in my side project there are moments when I have to ask myself, what is the lesser evil. Unfortunately not always is the answer straightforward and it's really "it depends".
One constant truth in software development is that in time development comes to standstill. To this point we can arrive through several ways, natural end of life, change of service providers, loss of know-how, clutter. In this post clutter and loss of know-how will be discussed more than two first two. There's very little that refactoring could do in those cases.
First project I want to discuss was eight years old project at a bank based on Flash. Luckily for the project it was very modular and very well documented project, probably the best documented project that I've worked on as long as one was willing to sift through eight years worth of documents and legislation (it's still a bank).
I was on this project during its last six months. At that time everything showed its age, from code to UI. It would have been a prime candidate for codebase refactoring and UI overhaul. The reasons why I would be against undertaking such endevour were:
- Adobe started phasing out Flash/Apache Flex
- Plans to replace with newer technology
- Not enough people (Not everywhere are UX and UI designers valued)
Second project to discuss was a group of apps, ranging from three to 18 years old. Unlike the banking project, documentation older than decade was in the form of code, last five or so years were available in form of JIRA tickets. A lot of people worked on this project throughout the years, so it had two issues, loss of know-how and clutter.
Clutter, fortunately, wasn't the biggest issue. It made fixing bugs and implementing new features harder and making sure my back-end leaning colleagues were consitent felt often times like herding cats.
Loss of know-how was more painful. First of all there were screens that allegedly someone was using but when I asked about them no one was able to tell me how to reach them. So during my first year on this project, they were urban legend to me. Fortunately no complaints were made about them for years.
On more serious note, there was a place in application where someone some time ago created their own undocumented framework. The issue rose when a customer reported an usability bug. From anecdotal experience from developer before me, when they worked at that area it usually took them the whole sprint to fix anything.
In this case refactoring is recommendable but other factors may apply:
- When is the estimated end-of-line for the app?
- If an app is supposed to be switched to maintenance mode within a year or two and no big features are planned, it's reasonable to leave it as is
- Does it block other parts of app?
- Badly implemented authentication needs to be refactored as soon as possible.
- A standalone form which causes a minor glitch when a page redirects to it and fixing it means spending weeks on it, is probably not worth the effort until slow months
On my side project the core things work. Unfortunately there's a dark place in taxonomy that needs to get fixing. So there's no question that it needs refactoring and it will get refactored. The question is when.
Side projects like any other project have a laundry list of to-dos and to-be-dones but unlike day job projects the time is more limited. Since we are in the pandemic and at least partial lockdown where I live is imminent in next couple of weeks my plan is to look into it during my stay at home vacation soon.
Refactor every once in a while. If you choose not to, expect slower development and high turnout among developers because not a single soul is happy working in bad code base.