Comment by treffer | Hacker News Reader

Comment by treffer | Hacker News Reader

"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 anyone relying on you, too. So if this happens org wide then features and projects may ship days to weeks later.

Oh and what are you doing on Fridays then? Less relevant work? If you stick with priorities then you are just queuing up more changes for Mondays, leading to nice higher risk deploy Monday. You simply can't gain stability with skipped Friday deploys without changing / ignoring work priorities for Fridays.

So yes, this should be comparable to such a reduction.

Oh, and Friday deploys ruin your weekend? That means you have really high detection and mitigation time. With 1h detection time and 2h recovery I could still with low risk deploy Fridays, 5PM, wait 1h and enjoy a weekend after wrapping up my work.

I have always shipped on Fridays. It never ruined my weekend. Even though I did have a few fun screwups (which sometimes required help from my coworkers).

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 are supposed to be automated. Moreover, if your code is allowed to be released next Tuesday it has to be merged by 4PM this Thursday. I still spend 100% of my time working, including Fridays. Because not all coding is releasing, and not all software engineering is coding. It's hilarious that someone would think if you're not releasing on day X you're not working. Sounds like straight out of Dilbert cartoon where some management type thinks I'm releasing my code every day.

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?

47.6% of statistics mentioned in comments are completely made up

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.

> Yes, that probably describes (a very high percentage) of companies. So what?

So good practices are not widely used; therefor the state of the industry on average, is poor.

It's absolutely not ridiculous on every level.

What is ridiculous is when not releasing on Friday means that "your metrics go up and that is bad". This is one of the reasons I hate metrics for software engineers. I should be able to put up a PR any day of the week without holding back committing and PR'ing just because there's a natural 2 day delay that will fuck up my metrics.

I will decide if this is something that needs merging now and be out in an hour even though it's Friday or if it can wait. And for that I need to not have perverse incentives. Just like I need to not have perverse incentives to make your Thursday cutoff by bypassing good engineering. If I can merge now or in two hours and it makes just a two hour difference and nobody cares for some dang metric, then I am more likely to take the time to add that one extra test that catches the bug. Before it hits a customer.

But in no way do I ever want to be restricted ever again from having a fix roll out within the hour. Our hourly deploy process (fully automated) is awesome. Never. Again. Without. It.

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.

> 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.

I’ve worked at multiple places that release every day. It’s not that hard.

Reply on news.ycombinator.com