| Allow me to try: Feature Flags inherently introduce at least one branch into your codebase. Every branch in your codebase creates a brand new state your code can run through. The number of branches introduced by Feature Flags likely does not scale linearly, because there is a good chance they will become nested, especially as more are added. Start with even an example of one feature flag nested inside another. That creates four possible program states. Four is not unreasonable, you can clearly define what state the program should be in for all four states. Now scale that to a hundred feature flags, some nested, some not. It becomes impossible to know what any particular program state should be past the most common configurations. If you can't point to a single interface in a program and tell me all of the possible states of it, your program is going to be brittle as hell. It will become a QA nightmare. This is why Feature Flags should be used for temporary development efforts or A/B testing, and removed. Otherwise you're going to have a debugging nightmare on your hands eventually. Edit: Note that this is different from normal runtime configurations because normally runtime configurations don't have a mix of in-dev options and other temporary flags. Also, they aren't usually set up to arbitrarily add new options whenever it is convenient for a developer. |
Branches are difficult to reason about? Yes, I agree.
Are branches necessary to make the product behave in a different way in some circumstances? Most of the time.
Do those circumstances require a branch? Unless you’re super confident about some part of code, yes? But why would you be?
Runtime configuration is not about making QA easy. It’s introduced because QA has been hell already so you can control rollout of code which you know wasn’t properly QA’d - or it was but turns out the thing you built isn’t the thing users want and the release cycle is too long to deploy a revert.
I’d say ‘branches are bad but alternatives are worse’.