[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.