Nice to see an old article of mine referred in that article (A Taxonomy of Variability Realization Techniques). Not my best work. The publishing date reflects that. We wrote most of that while I was still living in Sweden (I moved away in 2000), I completed my Ph. D. in 2002 and and after a post doc left the academic world in 2004. This paper was bounced around editorial boards for a while before we finally got it published.
In any case, the thing that we tried to make clear with that paper is that there are different ways to make software do different things (variability) and that these techniques have trade offs. That's still true today and people using the wrong ones make life harder for themselves and their users.
The main trade off is when you have to lock in your choice. With compile or build time feature flags, you are stuck with whatever you set before you ship the binary. You can't change it after. A change will require users to update their software. Configuration gives more flexibility. That breaks into runtime configuration and before runtime configuration.
The broader context here is the notion of companies that build multiple products using the same code base. How do they differentiate products from each other. How do they create new variants. And how do these get configured. Some companies cam up with really complicated ways to do this. The further back you have to go to change a choice (e.g. making source file change vs. setting a checkbox in a configuration screen), the more expensive it gets.
> While documentation is often disliked, it is essential for configuration options, because [...] options are only added to a text file with a one-line comment at best.
This resonates. Feature Flags over time devolve into a lovely career of code archaeology.
I read a thought-provoking article here about feature flags, entitlements, keeping them in but using a database or decoupling something something. Anyone remember the one? I am trying to grasp a principled way to collectively approach feature flags, entitlements, and authz.
In any case, the thing that we tried to make clear with that paper is that there are different ways to make software do different things (variability) and that these techniques have trade offs. That's still true today and people using the wrong ones make life harder for themselves and their users.
The main trade off is when you have to lock in your choice. With compile or build time feature flags, you are stuck with whatever you set before you ship the binary. You can't change it after. A change will require users to update their software. Configuration gives more flexibility. That breaks into runtime configuration and before runtime configuration.
The broader context here is the notion of companies that build multiple products using the same code base. How do they differentiate products from each other. How do they create new variants. And how do these get configured. Some companies cam up with really complicated ways to do this. The further back you have to go to change a choice (e.g. making source file change vs. setting a checkbox in a configuration screen), the more expensive it gets.