There is a strong opinion in software development about NOT releasing on Fridays. Friday deadlines (often the end of the work week or sprint) are pushing developers to rush to finish tasks. The temptation to push deployments through without adequate checks is high. What can go wrong?

• Compromised quality : A tendency to bypass proper testing or ignore test failures leads to unstable releases.

• Weekend recovery: If something goes wrong, devs have to give up their weekend to fix the issues, leading to burnout and dissatisfaction.

• Lost context: Developers who have shifted focus may not recall all the details. Troubleshooting gets more difficult.

Allen Holub stands firmly on the other side of the argument.
‍

Allen goes on to say that your code quality must be inadequate if you refuse to release on Fridays. While I generally hold Allen's opinions in high regard, the statement is quite bold.

Being completely averse to Friday releases can come across as dogmatic. Yet, I disagree with Alan on ‘no Friday releases’ being a sign of inadequate quality.

I have released on a Friday. Bugs can occur any time or weekday and Fridays are no different. It's fundamentally about setting expectations with your team. If there's an opportunity, however small, to reduce the likelihood of a weekend rollback or hotfix, I’m taking those odds any time. Because I value my own and my fellow engineers' weekends.

Sure, bugs should ABSOLUTELY be found before ever reaching production, but that’s not a 100%. I don’t see the issue with pushing a bigger release to Monday, if there’s no business need to get it out on Friday.

Daniel Draper
Lead engineer at Octomind