Friday work plans
After a long week of work, what comes to mind for a Friday afternoon?
Checking out a bit early to get your weekend started?
Getting a drink with the crew?
How about a Friday evening deployment?
No deployments at all?
When I talk about Friday deployments I am not talking about a hotfix for a blocking production issue. Obviously, you have to fix that ASAP.
I am also not talking about minor cosmetic changes. Text copy change? Sure, go for it.
The type of deployments that I am saying should never be done on a Friday evening include:
- introduction of new functionality
- changes to existing functionality
- major refactoring of existing code
Any of the above changes could leave your users with non-working functionality, security, or performance issues.
Top reasons you should never deploy on a Friday.
1. Minimal support on the weekend
People have lives. Once people leave the office and head out on their weekend adventure, they are likely not going to check their work email to make sure that everything is running smoothly.
Don’t expect people to be available and don’t expect people to answer their phones.
2. Leads to bandaid fixes
Deployments don’t always go without any issue and require a hotfix. However, when people are in a rush and pressured to wrap things up they tend to make poor decisions.
A developer is more likely to put in place poor quality code so that the team is not held back. Also, critical steps in the development process are often thrown to the side. Important things like peer code reviews and regression testing.
3. Poor morale
Let’s face it. Nobody wants to work late on a Friday. Forcing your development team to constantly have to endure the stress of a Friday deployment has a toll on their morale.
I have seen team members who are usually calm exhibit a lot of stress, anger, and anxiety.
Happier teams typically result in better output and better quality.