If You Trust Your Developers To Deploy Code, You Should Trust Your Developers To Toggle Feature Flags
At InVision, we've been using LaunchDarkly as our Feature-Flags-as-a-Service (?FFaaS?) provider for several years now and it's completely changed the way that we think about our application development and deployment work-flow. Almost all features are coded behind a feature flag so that we can safely decouple the concept of "code deployment" from the concept of "feature rollout." And while all of the teams at work are sold on the idea of feature flags, there is still some contention around who on the team should have permissions to toggle or increase the rollout of a given Feature Flag. So, let me answer that question for you - who should have permissions: Your engineers.
As a product company with a user-facing landscape, you want your engineers to be using feature flags. Feature flags force engineers to think about the safety of their code, the complexities of a rolling deployment, and the positive experience of your users. Feature flags are "the way" to do development. As such, you should remove as many points-of-friction that you can regarding feature flags. That means creating, manipulating, and deleting feature flags should all be something that your engineers can do.
If you make it hard for engineers to implement and consume feature flags, then your engineers won't use them. And, you should want your engineers to use them. You should want to create a culture in which the "right path" is also the "path of least resistance."
| |
|
|
||
| |
 |
|
||
| |
|
|
Philosophy aside, engineers should have the permissions to toggle feature flags for a very practical reason: they are the ones that understand how the system will be affected by the newly-enabled code. New code places new demands on a system. And, those new demands can have catastrophic affects. Which is, not coincidentally, the very reason to use feature flags in the first place.
When an engineer enables or changes the feature flag that they put in place, they understand how to monitor the system for changes precipitated by said feature flag. Whether it's database access graphs, HTTP latency graphs, memory usage graphs, disk-space usage metrics, file input/output operations, garbage collection patterns, or error logs - the implementing engineer is the one most capable of noticing negative outcomes and disabling feature flags before failures begin to propagate through the system.
If you take those permissions out of an engineer's hands and you put them into the hands of a Product Manager or a Marketing Analyst, you counteract the safety-net provided by the feature flag. You create a disconnect between the ability to change a system and the ability to monitor changes to that system.
Of course, I'm not saying that engineers should be the only ones who can enable a feature flag. If you want your Product Managers and Marketing Analysts to enable feature flags, you can absolutely let them. But, you should probably have an engineer overseeing such activities.
At the end of the day, if you trust your engineers to deploy code, you should trust them to enable feature flags as well. Such trust will become the bedrock of a more empathetic team that develops more stable software which leads to a more positive user experience (UX).
Reader Comments