←back to thread

Netflix buffering issues: Boxing fans complain about Jake Paul vs. Mike Tyson

(www.sportingnews.com)
492 points storf45 | 1 comments | 16 Nov 24 03:42 UTC | HN request time: 0s | source
Show context
softwaredoug ◴[16 Nov 24 17:53 UTC] No.42157774[source]▶
The way to deal with this is to constantly do live events, and actually build organizational muscle. Not these massive one off events in an area the tech team has no experience in.
replies(9): >>42158542 #>>42158774 #>>42158782 #>>42158854 #>>42158930 #>>42159942 #>>42160430 #>>42160978 #>>42168444 #
mbrumlow ◴[16 Nov 24 19:56 UTC] No.42158774[source]▶
I have this argument a lot in tech.

We should always be doing (the thing we want to do)

Somme examples that always get me in trouble (or at least big heated conversations)

1. Always be building: It does not matter if code was not changed, or there has been no PRs or whatever, build it. Something in your org or infra has likely changed. My argument is "I would rather have a build failure on software that is already released, than software I need to release".

2. Always be releasing: As before it does not matter if nothing changed, push out a release. Stress the system and make it go through the motions. I can't tell you how many times I have seen things fail to deploy simply because they have not attempted to do so in some long period of time.

There are more just don't have time to go into them. The point is if "you did it, and need to do it again ever in the future, then you need to continuously do it"

replies(6): >>42158807 #>>42158896 #>>42159793 #>>42159969 #>>42161140 #>>42161623 #
andai ◴[16 Nov 24 20:12 UTC] No.42158896[source]▶
This is great, but what possible counterargument is there? We should prolong indefinitely a spooky ambiguity about whether the system works or not?
replies(6): >>42158935 #>>42158962 #>>42159076 #>>42159241 #>>42159259 #>>42159634 #
rconti ◴[16 Nov 24 21:46 UTC] No.42159634{3}[source]▶
The counterargument is obvious for anyone who has been on call or otherwise responsible for system stability. It's very easy to become risk-averse in any realm.
replies(1): >>42160484 #
andai ◴[16 Nov 24 23:27 UTC] No.42160484{4}[source]▶
Doesn't ensuring stuff actually works tangibly lower risk?
replies(2): >>42161786 #>>42161813 #
1. Jach ◴[17 Nov 24 03:34 UTC] No.42161786{5}[source]▶
Not exactly, but it's worth the experiment in trying things anyway. Say you currently have a release once every few months, an ambitious goal would be to get to weekly releases. Continuous enough by comparison. But 'lower risk' is probably not the leading argument for the change, especially if the quarterly cycle has worked well enough, and the transition itself increases risk for a while. In order for a committed attempt to not devolve into a total dumpster fire, various other practices will need to be added, removed, or changed. (For example, devs might learn the concept of feature flags.) The individuals, which include management, might not be able to pull it off.