Arguments for A Read Only Fridays

A while back I came across a hashtag on Twitter: #ReadOnlyFriday. It’s not a super popular hashtag but pops up every once in a while 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 not obvious, it’s to avoid the introduction of bugs or new issues to software or a website before the weekend.

To me, it also means that Friday is not the day for a new website or application to be launched.

The Expectation is Often, “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 afternoon and evening as people start to focus on their weekend and not whatever widget or service the website is trying to sell.

It also gives the weekend for testing, to catch any issues and get them resolved before traffic picks up again on Monday morning.

So, What’s The Problem?

The problem is that developers (and our clients) need weekends too. Though I am fairly guarded about my weekends and evenings to obtain some kind of 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 actually have a few solid arguments for a read-only Friday.

Exhaustion Leads to Mistakes

For starters at the end of the week, we are all tired. Developers, designers, and the clients who hire them have probably been working all week, the propensity to make mistakes and miss details when one is tired is much greater than after rest.

That is just a human fact. In any deployment, whether it be a whole website or just 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 smooth are low. It’s not an issue of quality.

You could have the best development team and have 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.

Now your site or feature is launched, and everyone is on call for the weekend. The client must test and review to make sure everything is working as it should and the developer must also test 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 who were put 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 exactly what the deployment is and what kind of 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 not only disruption to regular traffic to your site but also the disruption to your work, sleep, rest, and sanity (and that of your development team).

The Exception to “Read Only”

Bugs of course are the exception. When I talk about not deploying on Fridays, I am of course not suggesting that absolutely nothing gets deployed. There are times when bugs must be squashed, security patches must be applied, and errors must be fixed.

I’m only advocating for a read-only Friday when it comes to new sites, features, and other major changes.

Now go enjoy your weekend!