A few months back I am came across a hashtag on Twitter: #ReadOnlyFriday. It’s not super popular hashtag but pops up every once and a while and as a web developer I love this concept!
Read-Only: No Changes Allowed
The hashtag refers to permissions given to a file on a server/computer whereby it can not be changed and as the name suggests, is read only. However in this context it means no major changes or deployments of websites, applications or features 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 prior to the weekend. In my book it also means that Friday is not the day for a new site or application to be launched.
In the nearly 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 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?
All this sounds great, so what is the problem? The problem is that developers (and our clients) need weekends too. Though I am fairly guarded about my weekends and evenings in an effort to obtain some kind of work/life balance, I’m really 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, dealt with and the launch will go smooth is 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 1AM or anything like that. I’m talking after 7AM, 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 chances 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 came 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).
Bugs of course are the exception. When I talk about not deploying on Friday’s I am of course not suggesting that absolutely nothing get 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.
No go enjoy your weekend!