Why should we fix if it’s not broken?

In this digital world, we strive to keep our stuff updated. Not only that, but we always try to make it better from time to time, preventing our stuff from being obsolete. Though sometimes, it’s better to stick with the proverb don’t fix it if it’s not broken.

Let’s read the story of our friend, Diamond Jack,or we may call him  D.J.

The Story

On that snowy night, at the beginning of 2019, D.J. is working on his client’s project site from his own home. The project has been going well. It’s based on WordPress and powered by some popular plugins.

Things had been going well in 2018. D.J.’s client, the owner of the site, wants to make it better in this 2019. He asks D.J. to replace some plugins which already served the site well since the beginning, with some newer plugins which claims can do a better job.

The intention is clear. The expectation is high. The developer of these newer plugins markets their products well. It successfully persuades the client’s mind to believe those new plugins will truly do a better job than the old, popular plugins which already served the sites since the beginning.

At first, D.J. hesitates to do the job. He discusses the matter with the client. He believes that there is no need to fix something that’s not broken. He has a hunch that doing this will lead to several disasters on the site.

However, the client insists on his choice. He even treats D.J. that he’ll look for another WordPress developer to do this. This eventually will take away the only project D.J. has been working for the last several years. The project that he makes a living of it.

Fix things which didn’t break

Since he has no other source for income except this project D.J. accepts the client’s decision.

Here are what our friend does:

• Login to the WordPress admin dashboard, as he usually does. He never uses the “Remember me” function, so he needs to login again.

• He makes sure the last backup has run successfully. 

• Since it’s run successfully, he does a double check on the Google Drive where he set up the destination to save the backup of the whole site.

• Since there are some updates and changes that occurred after it completes the last backup, he fires up the backup process again. He uses the Updraft plugin to do the job.

• Once it’s done, finally, our friend is deactivating these plugins.

• He installs all the newer plugins and activates them all.

• Then, he sets up the configuration of these new plugins, as needed. The same configs as he’s done on old ones.

• At last, after he does a manual check on the whole site, he removes those old unused, inactive plugins.

• Because our friend is a cautious person, he does a manual check on the whole site once again.

After he’s confident that everything is going well, he contacts his client to tell him that everything is complete and tested. The client is happy, and he checks the site as soon as possible.

The client confirms everything is going well and ask D.J. to do the other tasks on the backlog to expand the site more.

Disaster is coming

Fast-forward to several days later…

In the middle of another snowy night, D.J.’s phone keeps ringing while he’s sleeping peacefully.

Since it keeps ringing, he wakes up and checks on the phone. It’s from the client. He’s yelling that the  site has been down for almost an hour and he can’t figure out what’s going on there.

Still sleepy, our poor friend opens up his PC and does some quick checks. Almost half an hour has passed, and he is still struggling to find the cause of the problem.

The admin dashboard is, fortunately, accessible. Yet, the front-end page is always giving  the page redirects too many times. ** **

Still, in a panic, he finally tries a simple and quick experiment by deactivating all of those newer plugins he put on several days ago.

The luck is on his side this time. After deactivating all of them, the site works again. The front-page and other pages are working fine now.

He tells his client that for now, he will revert to the old plugins and keep those newer plugins inactive until he’s confident he could fix the problem caused by them.

The client agrees. It’s better to have a running site rather than keeping newer cool plugins while it breaks the site.

The verdict

Regardless D.J. can find the cause or not, for most cases, if it ain’t broken, trying to fix or update it doesn’t worthy of the time. Not to mention that this exposes some unknown risks that may happen several days after the fixes or updates.

Our friend’s story can be a real example use-case. If it’s not broken, why should we fix it?