Live data from Hacker News

Never Ship on Fridays

octomind.dev

51–55 of 55 posts

Re: Never Ship on Fridays

#51
post #23

Earlier quoted context omitted.

Same for me. I think we are all talking like we work on the exact same product. I work at an agency with many codebases, from different clients. Some we inherited that don't yet have good coverage, some with notoriously brittle third party integrations we can't truly test until it is in the live data environment, and some with clients who are very unresponsive and if we planned a Friday deploy the chances of a no-go…

It sounds like you're deep into scenario 2. The mention of "sign off or testers" is a dead giveaway. "testers" being people not automation. likewise "sign-off". It also sounds like while you know that better exists, the "commercial reality" is "not on this project". I've been there too. I don't see this as being in conflict with what I said above.

> It sounds like you're deep into scenario 2.

Arrgh, I meant to say, "scenario 1" - the second scenario.

The first scenario is numbered 0, because it has zero process.

Re: Never Ship on Fridays

#52
post #46

If you can’t release on Friday: - the quality of your tests sucks, fix that with high priority - your CI/CD process sucks, fix that quickly There’s absolutely nothing wrong with releasing on Friday if you’re doing things correctly. And the meme that we shouldn’t ship on Friday needs to die.

I’ve literally never seen a codebase with 100% branch coverage from integration tests. There’s always some risk of handing a corner case badly with invalid writes. Now you need experts to write ad hoc tools to repair what’s in your datastores, and you’re really screwed if enough of those experts are unreachable until Monday.

Re: Never Ship on Fridays

#53
post #39

Earlier quoted context omitted.

The core of your argument is that it's the worker deciding this, and that they don't want to fix issues over the weekend. That's not true. It's the business deciding that they don't want to ship bugs on Fridays and then take the hit for customers having a bad experience over the weekend if the issue can't be resolved. What if you let someone deploy on a Fri and then they go skiing for the weekend? Sure, someone else…

Indeed, it's the business making the (IMHO poor) decision that the best way to address this issue is more manual oversight, and preventing release at certain times. There are often other, better ways to address the underlying issue; "no releases on Friday" is a band-aid fix.

First off, we're still saying we deploy 16 days out of the month. I'm sorry that's not good enough for you? Do you want cookies from management for deploying every single day and on christmas eve? We'll host an extra pizza party in your honor (no bonuses this year, even though you did 33 deploys on Fridays).

Not to mention I worked at places that deployed twice a month, or deployed once a month, only with CTO intervention, which took four+ hours and multiple devops and engineering people doing manual shit, even with Kubernetes etc. So individual engineers deploying by themselves 16 days out of the month is "manual oversight" and "poor business decision". what a joke.

Also, what, a band-aid fix? I wouldn't work at a place that made me deploy major stuff on Fridays, first off. I have a life, so I'll take my bandaids, thanks. You think because people write tests and follow a spec that you can deploy MyBigFeature on a Friday without issue? absolutely not.

Re: Never Ship on Fridays

#54
post #53

Earlier quoted context omitted.

Indeed, it's the business making the (IMHO poor) decision that the best way to address this issue is more manual oversight, and preventing release at certain times. There are often other, better ways to address the underlying issue; "no releases on Friday" is a band-aid fix.

First off, we're still saying we deploy 16 days out of the month. I'm sorry that's not good enough for you? Do you want cookies from management for deploying every single day and on christmas eve? We'll host an extra pizza party in your honor (no bonuses this year, even though you did 33 deploys on Fridays). Not to mention I worked at places that deployed twice a month, or deployed once a month, only with CTO interve…

There are befits to small batches, short cycle time and completing at will.

They are nothing do do with what management wants or rewards.

I'm sorry to hear that you have only worked at places that are unaware of or unwilling to do good practices.

Your commentary on the whole is defensive, ignorant, rambling, ill-tempered and borderline insulting. It lacks the basic respect necessary to engage meaningfully, rather is more likely to create conflict. No further response is needed, thanks.

Re: Never Ship on Fridays

#55
post #53

Earlier quoted context omitted.

First off, we're still saying we deploy 16 days out of the month. I'm sorry that's not good enough for you? Do you want cookies from management for deploying every single day and on christmas eve? We'll host an extra pizza party in your honor (no bonuses this year, even though you did 33 deploys on Fridays). Not to mention I worked at places that deployed twice a month, or deployed once a month, only with CTO interve…

There are befits to small batches, short cycle time and completing at will. They are nothing do do with what management wants or rewards. I'm sorry to hear that you have only worked at places that are unaware of or unwilling to do good practices. Your commentary on the whole is defensive, ignorant, rambling, ill-tempered and borderline insulting. It lacks the basic respect necessary to engage meaningfully, rather is…

> There are befits to small batches, short cycle time and completing at will.

That has nothing to do with deployments on Fridays.

> you have only worked at places that are unaware of or unwilling to do good practices

I didn't say that. I also worked at places that did small deploys daily. But we still didn't deploy on Fridays. I deploy with my own projects, to production, many times each day. But I still try to avoid Fridays.

> No further response is needed, thanks.

I disagree. You complain about the industry as a whole but can't deal with basic criticism to back it up.

Post reply on HN