> But following that reasoning, why not also avoid shipping after 4PM?
Yes, exactly! Don't ship after 4 PM either!
Yes, exactly! Don't ship after 4 PM either!
For people who work on applications they are often only hurting themselves if things break, so the risk profile is different. Maybe you don’t even have any customers, maybe your customers are consumers who are just not able to place orders.
IMO these groups often talk past each other (although as someone who works on infrastructure I think we often consider application developers’ more than they consider us, because they are our customers, and to them we are doing best when they don’t need to think about us) which leads to all these arguments from “Ship fast ship often - nobody uses our mostly static website which is easy to test, so who gives a fuck if it breaks” to “canary every change and carefully A/B test it with long release times to ensure it is safe”.
Things can and do break. It's impossible to test everything. That's why.
Your wording seems to indicate that you work by yourself. That's fine, but things change when large teams and systems are involved. You can't vouch for every single change or the inter-dependencies between all systems.
It's pretty elitist too. "Your code only breaks because you suck" doesn't make for good software engineering practices. Everyone makes mistakes.
If you have a micro service that takes requests over / foo and /bar and returns JSON that needs to fit certain properties, and you’re submitting a change to fix a corner case bug or add a new property that isn’t read, sure.
If you are working on low level networking infrastructure that is used in tandem with thousands of different workloads you need to support, won’t work.
Eventually, your totally avoidable gamble will backfire.
You know where I did get pings all the time? In companies that had strict release windows and would never deploy on Friday. Which in result motivated people to "push now & hotfix later" to meat the release cutoff date.