3 ms·

I was equally confused, and found: https://docs.microsoft.com/en-us/dotnet/architecture/cloud-native/feature-flags https://docs.microsoft.com/en-us/dotnet/archi

I was equally confused, and found: https://docs.microsoft.com/en-us/dotnet/architecture/cloud-native/feature-flags https://docs.microsoft.com/en-us/dotnet/architecture/cloud-n... It says: Feature flags are built upon conditional logic that control visibility of functionality for users at run time. In modern cloud-native systems, it's common to deploy new features into production early, but test them with a limited audience. As confidence increases, the feature can be incrementally rolled out to wider audiences. Looks like this supports an advanced form of, let's be generous, integration testing. Other uses mentioned by the article: Restrict premium functionality to specific customer groups willing to pay higher subscription fees. Stabilize a system by quickly deactivating a problem feature, avoiding the risks of a rollback or immediate hotfix. Disable an optional feature with high resource consumption during peak usage periods. Conduct experimental feature releases to small user segments to validate feasibility and popularity. All of this sounds to me like an urge to release before something is technologically mature. (note, not functionally mature, that's just A/B testing). Sometimes I wonder that if you need these things, are you really sure about anything you're doing at all? I don't mean the individual developer, I mean the software industry at large. Imagine a civil engineer saying: yeah we're gonna build a new bridge here, and we're gonna let in only like 10 cars a minute, just to see if it holds. Then later, as we get more confidence, we can open it up more. or We're gonna add a way to temporarily block this off ramp from the highway to the city. If it gets too busy we can just block the off ramp, and everything will be fine. I feel that most of the reasons mentioned above, except for A/B testing, are kind of bogus. Maybe somebody with more experience can share a counter view.

abridgett 4y ago
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 4y ago
  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.

abridgett 4y ago

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 4y ago
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.