Feature Flags and technical debt
If you start using Feature Flags, you normally end up with a highly configurable system that can change its behavior at runtime – normally by many flags that are scattered across multiple configuration sources. The flags tend to have dependencies between each other, so enabling or disabling flags exposes a great risk to the stability of the system. You managed to escape merge hell by avoiding parallel branches, but ended up in feature flag hell, with hundreds of flags that nobody knows what they are for.
To avoid this, you should follow these best practices:
- Metrics: Even with all the value they provide, Feature Flags in your code are some kind of technical debt. You should measure them as you do code coverage or other code-related metrics. Measure the number of Feature Flags, how long they exist (duration), how they evaluate in each environment (value, 100% true in production probably means the flag can be removed), and how often...
