Programming

17495 readers

46 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Follow the programming.dev instance rules
Keep content related to programming in some way
If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities [email protected]

founded 1 year ago

MODERATORS

snowe

Ategon

[email protected]

On developer dogma #3 : Never ship on Fridays (www.octomind.dev)

submitted 11 months ago by [email protected] to c/programming

18 comments fedilink hide all child comments

you are viewing a single comment's thread
view the rest of the comments

[–] [email protected] 7 points 11 months ago (1 children)

Again: if the changes are small enough and you have automated checks in place, they should not require manual intervention.

You've used the magic word "should". "Should is famous last words." The trick to keeping developer talent is not to risk the developer's weekend plans on "should".

And yes, maybe I'm only risking our cloud ops person's weekend plans. Same principle applies.

Every change that isn't already an active disaster recovery can wait for Monday.

[–] [email protected] -2 points 11 months ago (1 children)

Every change that isn’t already an active disaster recovery can wait for Monday.

I honestly fail to see the difference between "don't deploy on Friday if this can wait until Monday" and "don't deploy on the evening if it can wait until the next morning".

The idea of CD is that changes are small and cheap. No one is saying "it's okay to push huge PRs with huge database migrations on a Friday", what is being said is "if your team is used to ship frequently and incrementally, it won't matter when you ship and your risk will always be small."

[–] [email protected] 4 points 11 months ago (1 children)

I honestly fail to see the difference between "don't deploy on Friday if this can wait until Monday" and "don't deploy on the evening if it can wait until the next morning".

Both are top tier practices.

If your team is used to ship frequently and incrementally, it won't matter when you ship and your risk will always be small."

Yep. That's all great advice.

But I'm just a veteran saying that all the preparation in the world doesn't compare with simply not inviting trouble right before the evening or the weekend.

Organizations that feel that they desperately need to take that risk, are doing it because they disrespect their team's time.

It can be the smallest risk in the world, but it's still a risk, and it's a completely unnecessary one (outside of an active in progress disaster recovery).

[–] [email protected] -1 points 11 months ago

Organizations that feel that they desperately need to take that risk, are doing it because they disrespect their team’s time.

Or they are aware they are not in a position to block deployments for 60 hours every week? I've felt more discouraged working at companies that blocked Friday deployments because "it could wait until Monday", and then when Monday came half of the team was blocked or waiting for some new data report that could have been running during the weekend.

It can be the smallest risk in the world, but it’s still a risk.

And it's up to the Engineering manager (or at least the Release Manager in places where that role still exists) to evaluate what would be the trade-off. If you say that a bug coming from a Thursday deployment could've waited until Monday, why can't a bug that has come from a Friday deployment?

I guess my issue is not in saying "Some things should not be deployed on a Friday", but with the generalization. Of course there are things that should be okay to deploy on a Friday, or a Thursday night, or when the manager is on vacation... Being strict about it seems anything but "respect for the team", but a general distrust of the people and the process.