Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Never Ship on Fridays

octomind.dev

Post reply on HN
Print view View original

21–30 of 55 posts

Re: Never Ship on Fridays

#21

Post by mvdtnz »

gnulinux wrote: post #11
treffer wrote: post #7

"Never ship on Fridays" is pretty high up on my antipattern lust. It's a nice way to phrase "how about we work 20% less at the same pay? It will help reduce the number of bugs / incidents we ship each year!". And it will help with that. But why do I say 20% reduction in work? Bugfixes and features that get fixed/finished on Fridays will ship 3 days later. Do your average lead time increases by >0.5 days. This impacts…

This is really really ridiculous. I've never worked for a company that has releases every day, even every day of the week except Friday. That's not how it works. The most I've seen was 2 days (Tue, Thu) but 3 was fine if you insisted too too much. In my current company we have only 1 day a week release: Tuesday. No other day is allowed or is even possible without someone spending tons of time doing manual things that…

> I've never worked for a company that has releases every day, even every day of the week except Friday. That's not how it works.

I'm sorry you've had bad experiences but it absolutely is how it works. When it comes to web based SaaS software, all high functioning organisations release multiple times a day. Daily releases are a bare minimum.

Re: Never Ship on Fridays

#22

Post by featuregag »

localghost3000 wrote: post #18
gnulinux wrote: post #11

Earlier quoted context omitted.

This is really really ridiculous. I've never worked for a company that has releases every day, even every day of the week except Friday. That's not how it works. The most I've seen was 2 days (Tue, Thu) but 3 was fine if you insisted too too much. In my current company we have only 1 day a week release: Tuesday. No other day is allowed or is even possible without someone spending tons of time doing manual things that…

I dunno man. I work for a fintech that does tons of volume and we release safely multiple times a day. We’re working towards releasing on every commit for true continuous delivery. Once you’ve worked that way you’ll never want to do it any other way.

The only way to continuously ship in many B2B or enterprise environments is with copious feature flags. You can’t just change shit out from under you multimillion dollar clients — that’s part of the deal. So you flag it all out. Then changing the flag is itself a deploy by another name, and you are damn sure you don’t do it on Friday.

Re: Never Ship on Fridays

#23

Post by ehnto »

master_crab wrote: post #6
philwelch wrote: post #4

Earlier quoted context omitted.

There’s actually another maturity level: 3. The processes are automated, and high enough quality that we can be confident that clicking the "go" button" will either result in the build/test/deploy pipeline halting due to a problem, or a good release going to production. But we still prefer not to release on Friday, because no CICD methodology is perfect.

This. Also, you rarely have a full idea how your downstream clients interact with the system that was changed.

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 because we couldn't get sign off or testers is pretty high. It is just all around easier to do midweek deploys in such an environment.

Do I envy the fully automated Friday deployment teams? Sure! But this is my commercial reality, and the pragmatic approach is to not deploy on Fridays.

Re: Never Ship on Fridays

#24

Post by SkyPuncher »

yobid20 wrote: post #8

100% agree with Allen Holub. If your policy is no-ship-fridays because you're worried about things breaking and having to work the wkd, then your code quality is shit and you need to get better at being a software engineer.

It’s all a trade off.

We tend to avoid Friday deployments because they give us no tangible benefit while increasing the chance of an out of band issue. At a practical level, our customers literally do not notice if something ships at 4pm on a Friday or 10am on a Monday.

As for velocity, we can move way way faster by risking some bad deployments. Catching bugs is an exponential time trade off. We could catch most bugs, but we’d move like molasses. Instead, we catch what’s reasonable then ship during periods where it’s likely for us to recover quickly and easily.

Most companies will benefit from fastest shipping velocity at the trade off of occasional bad deployments.

Re: Never Ship on Fridays

#25

Post by craigmcnamara »

mvdtnz wrote: post #20

Just another reminder of the absolutely terrible state of our industry. Imagine anyone in any other industry taking this ridiculous stand. "Oh we don't fit roofs on Fridays, in case our roof leaks and we need to bring the roofer back in on the weekend". "We don't do Friday wisdom tooth removals, would hate for the dentist to have to fix a problem in the weekend". "No we don't fit tyres on Fridays, our tyre guy doesn'…

Speak for yourself. In my shop we have CI/CD and we ship whenever we're ready to ship regardless of the day or time.

Re: Never Ship on Fridays

#26

Post by redserk »

yobid20 wrote: post #8

100% agree with Allen Holub. If your policy is no-ship-fridays because you're worried about things breaking and having to work the wkd, then your code quality is shit and you need to get better at being a software engineer.

And on what grounds/experience can you so quickly hand-wave all code that doesn't ship on Fridays as "shit"? This is lacking in nuance that anyone with experience would otherwise have.

Bugs happen. Sometimes bugs take a day or two to surface and aren't caught in dev/QA.

I would suspect there is a planning issue somewhere if an engineering team is brought to a standstill if they prefer not to ship on 1 workday of the week.

We save boring work for Fridays. We knock out quality-of-life patches/scripts/cleanup tasks. We'll review external and internal docs. We'll even explicitly verify the functionality of sufficiently large features, which has saved us a few times. Friday is our day to do tasks that improve quality.

I've seen enough weekends saved by not deploying on Fridays for me to be skeptical of any contrarian dogma that demands it's universal removal.

Re: Never Ship on Fridays

#27

Post by rk06 »

Now, if employees were to be paid 1.5x (+vacation) to work on weekends, then company would prioritize the quality and resiliency enough that Friday deployments won't become an issue

Yet here we are, ignoring the elephant in the room.

Re: Never Ship on Fridays

#28

Post by edmundsauto »

mvdtnz wrote: post #20

Just another reminder of the absolutely terrible state of our industry. Imagine anyone in any other industry taking this ridiculous stand. "Oh we don't fit roofs on Fridays, in case our roof leaks and we need to bring the roofer back in on the weekend". "We don't do Friday wisdom tooth removals, would hate for the dentist to have to fix a problem in the weekend". "No we don't fit tyres on Fridays, our tyre guy doesn'…

I don’t think this take is complete unless you include complexity and the risk of unintended consequences. We pretty much understand roofing, but software doesn’t struggle with the chains of the physical world and the base case can be significantly more complex.

Re: Never Ship on Fridays

#29

Post by kmoser »

mvdtnz wrote: post #20

Just another reminder of the absolutely terrible state of our industry. Imagine anyone in any other industry taking this ridiculous stand. "Oh we don't fit roofs on Fridays, in case our roof leaks and we need to bring the roofer back in on the weekend". "We don't do Friday wisdom tooth removals, would hate for the dentist to have to fix a problem in the weekend". "No we don't fit tyres on Fridays, our tyre guy doesn'…

> Just another reminder of the absolutely terrible state of our industry. Imagine anyone in any other industry taking this ridiculous stand. "Oh we don't fit roofs on Fridays, in case our roof leaks and we need to bring the roofer back in on the weekend"

Agreed, the industry operates on a much more janky level than many other industries, but this syndrome is by no means limited to the field of software development.

If your roof is functioning perfectly well, fixing a non-critical problem on a Friday is less safe than fixing it on a weekday because if something goes wrong the next day, it's better that the "next day" be a day when the roofers are available. All other things being equal, I'd say fix your roof on a Monday so you have the next four days to call the roofers back if things go wrong.

It's the same reason you're safer booking an early flight, or scheduling surgery early in the day: if something goes wrong, at least you will get bumped to later in the day. If your originally scheduled flight or surgery was later, and something goes wrong, you will likely get bumped to the next day.

Obviously this rule doesn't apply to emergency fixes: if your roof has a bad leak, and it's a Friday, and you know it's going to rain on Saturday, you're still better off having it fixed on Friday.

Re: Never Ship on Fridays

#30

Post by philihp »

popularonion wrote: post #15
kenrose wrote: post #14

Earlier quoted context omitted.

Dilbert... or any place that practices continuous delivery? Sounds like your current/previous companies have heavier weight release processes that reduces how often releases go out?

> Sounds like your current/previous companies have heavier weight release processes that reduces how often releases go out? Yes, that probably describes 98% of companies. So what?

When you control the devices to which you're deploying to, there is little reason why you wouldn't deploy as often as you can. It helps a great deal in isolating bugs to keep your changesets small, and you can either do that by slowing down the product iterations (and getting poor feedback from each), or releasing more often. This is ubiquitous with web development.

Weekly releases (or slower) is appropriate when you rely on users to update their software or firmware. Most mobile app development does this.

Post reply on HN