never ship on fridays #3

Since we created Octomind we've released 64 times out of which 9 were on Fridays. We don’t refuse it, but we value our developers' time off. My take #3 on a popular developer dogma.

an octoneer enjoying its weekend

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 Holub tweet screenshot 1.

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.

Allen Holub tweet screenshot 2

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
Daniel Draper
lead engineer at Octomind
read more blogtoposts