[abridgett]

You comparison with building bridges without adequate testing is unfair. It's about increasing control, not giving permission to lower quality.

In terms of rollout it's more like releasing new drugs - initially it's very small groups that will be tightly studied, over time these groups are increased in size (and monitoring is probably reduced in scope).

The use of feature flags to control rollout and "blast damage" from unexpected behaviour or bugs is really useful. Let me give a real example I was involved with - mobile app development.

You can never test everything (not every Android phone variant, nor every 3rd party app which may interfere). Being able to roll out a new feature gradually and then revert (or in our case even blacklist certain models) is key to increasing quality and reducing problems. It also accelerates development and (in my mind a _key_ benefit) reduces stress/anxiety for the developers.

[vouwfietsman]

Yeah that makes sense as a use case, I agree. I would still argue that it doesn't speak in favor of software development in general that we need this though, but I see that in your situation it would be useful.

But to further my point: why not solve this with traditional versioning? The user can just pick the version of the app that is compatible with his device, and report bugs about the newer version. I suppose the culprit there is the app store approval process that blocks you from doing fast releases? And you just have a single native app wrapping a web-app that loads from the server? Or perhaps the user cannot roll back the versions easily?

If so I think that is a manufactured problem. Not a problem that the developer can solve or be blamed for, but ultimately a problem that should not exist/should have been solved, but was invented/grown/ignored by circumstance. I mean that there is nothing in the problem space of the end-user that requires you to solve this problem.

By extension, the solution sounds like a band-aid to me, someone not familiar with the space. The user is no longer in control over the software he runs, and applications may break and recover at any time. To me that does not sound like an increase in quality.

Thats not to say that I don't see why you have problems, or that I think they can be completely solved by better quality control. What I mean to say is that the issues you describe sound like issues software developers have faced for years, and tackled with application versions.