Code Refactoring: when to leave and when to stay

as we all know that in most companies, it is hard to explain to a non technical person what is exactly code refactoring

usually I would say that I am fixing some errors and enhancing the application because I found a way to make it faster and easier to maintain

and of-course I always get hit up with the same questions:

• "why didn't you do that in the first place ?"
• "so all of our client applications need refactoring ?"
• "why didn't you account time with your scrum jedi (nickname for someone who just knows scrum, also gets referenced as scrum master as well) and made the code better months ago?
• "you are not going to waste days doing this aren't you ? because we have other important stuff to do that this non sense that you are talking about!"

and the list goes on with the complains, but if you want to blame someone for this action: you have to blame everyone on the team not just the developer(s) that worked on this project

say again? why everyone on the team should be blamed ? 😮

to make it simple why not explain it in a real life case scenario (that it actually happened with me), shall we ?

lets say that your client wants a website that sells handmade baskets and you get initial designs on Adobe XD for how the site looks like

you calculated all the features and aspects that you need to work on and turns out that it takes 1 and a half month to finish

then the client replies to the sales department that he will be using an external service that would handle stock management and this service gives him a card reader for in-store payments

the client didn't tell the sales department that this service might/might not provide a web solution for online payment and the sales department didn't ask the client nor researched about this service to know if it can do this action (mistake number one: not getting enough info)

but the sales department (without talking with the developers) eagerly and proudly told the client that this would save time for our developers so we will decrease the time to one month (mistake number two: taking a decision without consulting the rest of the team)

the next day, sales department sends a message on slack to the developers just the url of the service and said: "use this, client wants this service on the site" (mistake number three: lack of clarification)

scrum jedi said that we can still finish within one month if we worked hard (mistake number four: not standing out for the team when something wrong is going to happen aka not being realistic)

developers start working on the website and due to the time constrain, a-lot of stuff needed to be compromised for the sake of finishing on time (mistake number five: compromising clean code for time which obviously will regret it later on)

mid of the month, client sends email to sales department that this service will cost him a-lot and found another service that would do the same but costs less

sales department told client that it is not a problem, the developers can handle it within time (mistake number six: giving promises to thy client without keeping)

the code that has been written was so bad that it would take a-lot of time to just add one feature to make it work with the new service (mistake number seven: bad written code that is hard to improve or change)

one month passed, and the site isn't finish yet

client is upset from the company and from the promises that were given to him so he is going to sue the company because the baskets that he bought and in stock are costing him a-lot of money to storage them and the site is not ready yet (talk about 4000$/month place to store and 50,000$ worth of items)

sales department is apologizing to the client and promises to drop part of the payment just to not throw charges (mistake number eight: when you don't do your homework, someone is gonna pay for it)

CEO is disappointed from the scrum master, the developer team, and sales department to a point that overtime is no longer payable

design department wanted to get out of the "not getting paid for overtime" situation so they send a new complicated design for the website so that they can impress the CEO and the client (mistake number nine: trying to show off)

sales department shows client the new designs and client approved on it because he is getting new and extra features for free (as a way of apologizing)

code wise it is almost semi impossible to add extra features due to the compromises that have been done but with the new design: it will take more time to make the code adapt to the new design than dumping it and start over (mistake number ten: writing bad code that it has a huge chance of getting dumped )

five months later, the site isn't finished yet

what can we learn from this? 🤔

it would have made sense that the project time didn't decrease and given an actual real deadline so that the developers would have focused on writing clean code from the beginning and also it would have made more sense not to add more design constrains

but the world is no sunshines and rainbows also most likely you might work for those kind of people (might, not saying that you will but not everything will be shown to you from day one)

and what I did is that I left the company, because the blame was set on us (the developers) but clearly it was the whole team's problem (one's ego couldn't help setting the blame on thyself so set it on someone else)

even after I left, handling the code is an absolute nightmare and still not maintainable

refactoring it would be a waste of time

why should we refactor? 🤔

refactoring code is not depended on one thing but rather that on multiple scenarios:

• updating a library and making it adapt your code base
• making the code run faster and less resources than before
• making the code more readable and scalable

and the list goes on and on

and we face a problem that we don't know when to leave this code and start over or when to add to it

the dip 🗻

in Seth Godin's book called "The Dip" (goodreads link: https://www.goodreads.com/book/show/324748.The_Dip)

he explained that we all start with a small cliff (most known as the honeymoon stage) where you feel like you are on top of the world

then you roll down to a small dip and this is where things get interesting

see, after you rolled down to the dip you have two options:

• either climb another steeper cliff
• dip down deeper to a dead end (or he refers to it as Cul-de-Sac)

but the problem with most of us that we are afraid of climbing another cliff so we choose to dip deeper

but in reality, we dream of climbing that cliff

we cling up to something because we have feelings toward it 💟

mostly known as a the comfort zone, and it is one hell of a zone actually

it prevents you from moving forward, where you start to wish for stuff rather than implementing them

we hold sentimental feelings toward that unmaintainable code because we feel comfortable working on it

and we would have a hard time letting it go, but sometimes you have to hold the shotgun and shoot that project right in the face

it is okay to leave you know 😶

referring back to "The Dip" book, Seth also explained that it is totally fine to leave and find another cliff

if the chances of facing a Cul-de-Sac is high then leaving is the right option

same thing with code, if you have tried to refactor your code and you are facing a-lot of errors as you proceed then wasting time on it could lead to a never ending Cul-de-Sac

Compromises Compromises Compromises

not everything can be refactored and still behave the same thing so you compromise by keeping it or dropping it

as an example:

lets say that function A can output 1,2,3,4,5

and if you give a specific parameter, it can output the value you want from the same function

but function A is slow and causes some memory leaks

function B does what function A suppose to do: output 1,2,3,4,5

also function B uses some new features that would make it faster and doesn't memory leak at all

but function B can no longer output a value when given to a specific parameter

so you create function C which takes the values of function B and outputs a value based on the parameter given

from your perspective: do we keep function A or stick with functions B & C ? 🤔

well, depends on the application actually

if the implementation of functions B & C will cause some problems and headaches to be used in the application then sticking with A is a right solution

there is also a possibility that A is causing memory leaks and it is slow because it depends on another function that is not written properly so function A might not be badly written

in that case, refactoring the code is useless because the base is not properly build hence it would make more sense to drop the refactoring part and start from scratch

the business perspective of refactoring

in the real world, dropping something and starting over is a fools errand but in some case scenarios it is the only option

you don't see this in small projects that have a medium amount of data, you will see it in companies that have been serving the application for more than 10 years minimum

where there are huge amount of data being taken care of

if the company sees that creating something from scratch can save a-lot of time and money on the long run then definitely creating a new code base and working on it seems like a realistic option

but if creating a new code base and still generating the same amount of money and using the same amount of time but with a fresher code base, then it is not worth dropping the existing code for a new one. It would make more sense to allocate some extra time for some refactoring

and if refactoring isn't helping much or as expected then you can try to extend your legacy code with a newer code base that would supercharge your legacy codebase

take Facebook as an example:

Facebook is written in PHP, shifting the entire codebase to another language like Python or Ruby on Rails would not make that much sense

and PHP might have some limitations (not all languages created even and not all languages solve all problems)

hence Hack was created (https://hacklang.org/), extends on top of PHP

then extending the legacy code with other languages like Python but keeping the legacy code

the idea behind of it: from a business perspective, it would have made sense that Facebook would have changed to another code base if it didn't have that much of huge sets of data

it would have generated even more money (also saved more money) with the newer code base

but shifting to a newer code base could cause the company to lose a huge amount of money and possibly the inability to generate more money

in the end 🤯

depends on the condition that you are in actually, it is your job to choose the right decision whether to refactor or when to drop it and recreate it from scratch