A long time ago, I came across a hashtag on Twitter: #ReadOnlyFriday. It’s not a super popular hashtag, but it pops up occasionally, and as a web developer, I love this!
You can even find an occasional read-only Friday meme.
Read Only Friday: No Changes Allowed
The hashtag refers to permissions given to a file on a server/computer whereby it cannot be changed and, as the name suggests, is read-only.
However, in this context, it means no changes or deployments of websites, applications, or features to production on a Friday.
If the reason is unclear, avoid introducing bugs or new issues to software or a website before the weekend.
Friday is not the day to launch a new website or application.
Launch on Friday
In the over 20 years I have been building websites, I cannot tell you how many times I have been asked, or it has been assumed, that Friday would be the day we launch a new website or feature. It does sound good… in theory.
The common belief is based on the fact that many industries, especially B2B, see a dramatic decrease in web traffic on Friday afternoons and evenings as people start to focus on their weekends and not whatever widget or service the website is trying to sell.
It also gives the weekend for testing to catch any issues and resolve them before traffic picks up again on Monday morning.
So, What’s The Problem?
The problem is that developers (and our clients) need weekends too.
I am fairly guarded about my weekends and evenings to obtain a work/life balance; I’m not trying to be a jerk here and say I don’t want to put in the extra hours.
I have a few solid arguments for a read-only Friday.
Exhaustion Leads to Mistakes
For starters, we are all tired at the end of the week. Developers, designers, and the clients who hire them have probably been working all week; the propensity to make mistakes and miss details when tired is much greater than after rest.
That is just a human fact. In any deployment, whether a whole website or a new feature, everyone involved would be much better served if the full team was rested.
It Ruins Everyone’s Weekends.
The odds that every issue will be caught and dealt with and the launch will go smoothly are low. It’s not an issue of quality.
You could have the best development team and the best client team; when you create pressure around a launch at the end of the day, the week, or into the evening, there will be issues, as it’s the nature of complex technology.
Your site or feature is launched, and everyone is on call for the weekend. The client must test and review to ensure everything is working as it should, and the developer must also try and be ready to react to anything the client has found.
Let’s face it, it’s not fun for the client, and it’s not fun for the developer. It’s especially not fun for the employees on call for the weekend from either side.
So, When Should We Deploy?
I always recommend an early morning deployment, obviously not on a Friday, and by early, I’m not talking about 1 AM or anything like that.
I’m talking after 7 AM, maybe 8, or even later, depending on the deployment and what disruptions will be experienced on the site or application.
I argue this is a better deployment strategy because both the client and development teams are rested, and the chance for mistakes is much lower at this energetic time.
It also means that instead of a limited “on-call” team on both the client and developer’s sides, the full teams are available to help with any issue that may arise.
Finally, the early morning deployment time gives a full business day to devote as many resources as needed to test, monitor, and react to any issue that may come up.
I know clients are sometimes excited to launch a new site or feature, and I know they want to do it at the least disruptive time possible.
However, I urge you to consider the disruption to regular traffic to your site and your work, sleep, rest, and sanity (and that of your development team).
The Exception to “Read Only”
Bugs, of course, are the exception. When discussing not deploying on Fridays, I do not suggest that nothing gets deployed. There are times when bugs must be squashed, security patches must be applied, and errors must be fixed.
As a website maintenance company, we are often squashing bugs or fixing things, and these, by all means, are done on a Friday.
I only advocate for a read-only Friday regarding new sites, features, and other major changes.
Now enjoy your weekend!
