[ryandrake]

Maybe Continuous Delivery is the problem. What are these markets where customers want such frequent changes? As a user, I don't really want my software changing daily, weekly or even monthly. I don't want features to come and go depending on which arm of an A/B test I am in. I don't want to be part of the developer's "experiment" and metrics-gathering.

[gmueckl]

The actual need for continously delivery is mostly related to running public-facing services at large scale that need the ability to adjust to external events quickly, e.g. when defending against a new form of abuse requires an immediate software change.

Al other software could get away with deliberate release cycles rather than an urge to YOLO things into production. I just think that there is a fallacy in business leadership that ultra short turnaround times on features actually matter for a business.

[wbl]

Until you have the feature in production you do not know if it works.

[gmueckl]

Engineering is about making certain that stuff works before it enters production. If we claim to do software engineering, then that's just a simple part of doing our job. Everything else is just tinkering and hacking (the bad kind).

[ajb]

From an engineering point of view, yes. But not from the business point of view.

It's like a restaurant. You can make sure they new dish tastes like what you intended and isn't going to poison anyone, but until it's on the menu you don't really know if people will want to eat it or if it will be a success for the business.

This does make me wonder whether there's a place for a system where you split your usebase into N shards, and only deploy new versions to one of them; reducing the update rate from a user perspective by a factor of N. Of course, this means you have to maintain compatibility with N versions, but that's still better than N feature flags.

[alextingle]

That whole approach is so disrespectful of users. If you are a serious business, then hire sufficient QA people, and empower them to do their job.

Expecting your customers to do your QA for you is super common these days. But that doesn't make it right.

(What really infuriates me is the general lack of feedback channels that enable users to actually contribute to QA. With open source software, end users can at least open a ticket on the bug tracker. If it's a commercial product, all too often the only point of contact is a disempowered call-centre worker, who can't even log a bug for you.)

[wbl]

QA has the disadvantage of knowing how it should work. Users are not so burdened and very creative.

It can decrease the chances but isn't a panecea.

[tightbookkeeper]

how did they ship shrink wrapped software (including operating systems) that didn't even have the option for updating after the fact?

[bigstrat2003]

Agreed. Speaking as a user, I much preferred when the industry in general had a slower release cadence. I want to update once every year at most, and usually I want to update less frequently than that. Continuous delivery is a thorn in my side.

[SpicyLemonZest]

No individual customer wants frequent changes. They want changes they care about ASAP and changes they don't care about never. But unless I'm maintaining per-customer versions (which can make sense for high value enterprise customers!), promising user X that I won't make any changes until January necessarily means telling user Y that I refuse to resolve their showstopping bug report until January.

[Nullabillity]

You can backport bugfixes if they're critical enough.