Now if they had only bought a Mercedes as well, they could have chosen the self-breaking option to avoid the collision in the first place.

Many cars and especially planes & spaceships are have tons of systems like this.

I worked on a system that did things like in response to a primary datasource being offline would switch the queries it used to a different database to include substitute data and pass this back to be used instead until the primary store came back online. Three years after it was put in production this happened on one of the company's biggest and most important days of the year, and our SREs were sitting there calmly trying to solve the issue, ended up waiting until late at night to deploy a fix. It would have been reasonable for this service to just rely on the primary source, but we would have been offline for hours if this little trick hadn't been put in place.

For obvious reasons it is much more common to see this level of design in physical, life-critical systems like aerospace or automotive technology, but you do see it sometimes in software. Well designed services that under heavy load, various kinds of infrastructure failure, attack, or other kinds of scenarios well outside the bounds of normal expected operations intelligently compensate while signaling alerts with precise, useful information, and attempt whatever kind of recovery is possible.

This is hard to anticipate and often thankless to build in advance. It's always a stressful time when this behavior is visible, but it gives me a feeling of admiration for the perhaps long gone employees who built it.

Wildly off-topic but perhaps you’re turning off a TV without the streaming device itself shutting down?

I mean this is it, right? This is the big one. All these "tech" companies that are not actually selling software taking huge cuts off the top line, this can't be sustainable.

You can own the market for a while, but sooner or later someone is going to come along and disrupt you.

I am always amazed at how many repetitive tasks folks want to load up developers with. I think there’s a tendency among developers-turned-managers to see their job as crafting the perfect “program” of processes for their developers to follow, instead just automating these tasks. Like they say, the cobbler’s children have no shoes.

Fact remains though that back when everything was waterfall (proudly) and we shipped physical media to clients, when a bug often meant flying a support engineer out to the customer’s office, software was generally delivered more completed and vetted, and the QA group wasn’t allowed to report to the same org as developers because it was considered a conflict of interest. Now some software companies don’t even have a QA organization, we are inventing new organizational and technical structures to ensure that the developers are perpetually on call to resolve issues, and there is definitely a school of thought that says delivery of a complete product is an anti-pattern because after all every feature is just an experiment that you are testing on your users. But whatever, two different times, two different needs, two different practices, and to my point now we seem to be entering a new post-COVID era where just as waterfall doesn’t scale to a continuous delivery paradigm, “you build it, you run it” as practiced today is going to struggle with an “always on” business which has no “after hours” due to more flexible working schedules.

Are there companies today that run true 24/7? Sure, plenty, but they tend to be larger and have the staff to cover this. A great deal of business software today is still very fragile operationally and has deployment, management, and maintenance tied to the 9-5, M-F business schedule. I think it is going to have to evolve.

Specifically “doing agile” seems to encourage this, I always see lots of supporting infrastructure being skimped on so a new feature can be delivered faster, with some hand wavy plans to fix it in some future sprint.

Yeah, no thanks.

I am really struggling to understand the mindset here of what I assume are mostly well paid professional software developers. If I defaulted on a car loan (I don’t know the details exactly off the top of my head, but this entails more than just missing a payment) I’d be quite ashamed of myself and return the car myself with an apology. I cannot understand the mindset of someone who would feel justified keeping the car, much less getting angry at the method used by the bank to reclaim their property.

It’s not like this is a cheap car either where you’re threatening someone’s livelihood who is not going to be able to get to work.

Also, I think these help replace what might have been other meetings as well. Sometimes product people like to sit in and listen so they know exactly what's being released--I don't think they'd ever participate or get much value from a normal code review.

Also, I’ve done this with smaller teams, 5-6 people. If you had three or four times as many that might make for a long meeting.

- The quality of these reviews is better than any code review I’ve seen on feature branch reviews

- We review the whole collection of changes going out, on rare occasions when two changes conflict, you catch these

- Everyone keeps up to date with what is changing in the code base and why

- If for whatever reason there’s an issue after the deployment, it’s easier to fix because everyone has fresh in their head what has changed in this release