Forgive me, I don't understand your last sentence. It sounds contradictory vs "they got a lot more productive".

Your choices are often between these two:

1. Higher throughput, higer latency and correctness on one side.

2. Lower throughput, lower latency and some risk of faults on the other side.

It's like the difference between tcp and udp.

The question is: Where do you need to be? What are your requirements?

I rewrote an app that used to only deploy on weekends because we do a lot of processing on weekday afternoons and nights. I changed the deployd to the mornings.

I justified as saying if something breaks we have everyone there to fix it. Plus I'm not going to spend my weekend working if I don't have to.

My app has global traffic. Sometimes stuff breaks Sunday night and Asia is the first to find out.

Ugh, I know the feeling - one client I worked for would only do deploys a few times a year if that, and only at night. I mean we'd get extra pay or free time for doing night shifts, but really, it's not good practice.

It depends on what company you are.

Some who administers some SAP thing for a huge supermarket chain tells me they do all of their upgrades on weekends because their users aren't at work.

Makes sense for them, but it would be a crazy thing to do the consumer-focused interweb company that I work for.

You are assuming that monitoring and rollback solutions are bug free, always on and have 100% knowledge of what's going on. That is never true.

I agree I've never worked anywhere with really heavy duty CI, as in I've never worked somewhere that automated rollbacks were either trusted in all cases or business acceptable after something was production live. (Which is to say I haven't worked at places that had really significant scale.) And CI is only as good as your test coverage, which is to say if something esoteric is overlooked in your test suite...

That's fine, because when something breaks the day after you've pushed, it's Friday and everyone's in the office. People are still going to rush the deadline, but putting the deadline earlier means you have time to deal with stuff that breaks after the deadline.