| This is definitely an interesting challenge you bring up. I think regardless of the how difficult it is to remove a non-binary flag, the market has moved feature flagging away from just binary and merged with the concepts of remote configuration and experimentation, both of which require more than just ON/OFF states. For us, we're not trying to shy away from that challenge, so it forces us to come up with interesting solutions to the problem. A couple ways we're solving for this problem are: 1. Variable Schemas - We just launched a feature that allows for engineers to strictly define the acceptable values of any feature flag they are creating, so that as other team members interact with those flags, there are programmatic controls in place that create guardrails on the input. This also does double-duty in creating strongly typed code, so that usage in code is clear, easy to navigate, use and cleanup when the time comes. 2. Code Cleanup - An example of one of those solutions is our Code Cleanup CLI command. Regardless of what the flag type is (boolean, number, string, JSON) you can provide the prompt with what you would like the end state to be and the AST logic built into the CLI will create a proposed diff for your code wherever a DevCycle flag exists which you can then either edit further or submit directly for a PR. I 100% agree non-binary flags present a challenge, but we are definitely interested in finding unique ways to solve that problem. |