[kqr]

There's also the more insidious version of this where instead they go, "That sounds nice, but we really don't need it."

"May I ask why you don't need it?"

"Oh, we found that we spent so much time on deployments that we decided to do only one planned deployment per year now."

In this case, the people you're talking to have obviously only swept the dirt under the rug, but sometimes they honestly think they've solved the problem this way!

(And then they ask everyone to "work harder" because the competition is running circles around them. This usually means cramming more things into already big deployments and failing even harder than before.)

[imtringued]

I always thought this was strange. A lot of our deployments don't take time to actually do, they mostly take time to decide when the next deployment is and what should be included. If I could deploy as fast as possible I think I would end up spending less time.

[kqr]

I'm not sure what you mean. If you have the luxury of deployments not taking time, then why do you need to debate what to include? Just deploy as soon as anything is ready for deployment.

[jiggawatts]

"Normalisation of deviance" is a wonderful thing to Google.

I've seen people trying to justify a workflow what is literally 10,000x slower than the industry norm. Then patiently explaining to me that dealing with the fallout of that is necessary, and I was just being uncooperative.

A recent example is I showed a dev team how to identify and fix some crash bugs in minutes. Because they were "busy" and deployments require a mile high pile of paperwork, six months later those bugs are still occurring in production.

They're busy with BAU / support tickets, which is why they can't get around to doing a deployment of bugs they've already fixed.

Guess what the users in those tickets are complaining about.

I think they've fixed the same bug in like.. three separate un-merged, un-deployed branches.

This is what the opposite of CI/CD looks like.