The First Stages of Feature Flag Adoption

For quite awhile now, developers have used snippets of code to turn features on and off during runtime. These code snippets, more commonly known as feature flags, allow you to change features (or sub-sections) of your application without re-deploying. They help developers release code faster, with less risk. 

Feature flags are more prevalent than you might believe. At most companies, though, adoption begins at the grassroots level. Developers—usually within a single team, and often just a few individuals—implement a handful of feature flags in an ad hoc way. In these early stages, feature flags aren’t usually being considered at a systemic level. They’re meant to solve specific pain points at specific points in time. There is no formal program in place, and there are no plans to manage flags across teams. 

Initially, it makes sense to experiment with feature flags at a small scale. Self-built feature flag tools are a viable option when you’re just starting out. At this point, the underlying technology responsible for changing the flag values is usually either a static configuration file or a database table. The particular pain that this small team faces will become the focal point around which the minimum viable feature flag product is built.

Although they aren’t typically thinking about long-term usage at this stage, the team can see more potential use cases for feature flags. They set a plan in motion to start building a homegrown feature flag solution. These self-built systems are most often built around the technology originally used for the first few flags. While config files and database tables are not good long-term solutions if you’re looking to scale, each does have its benefits.

A config file is usually a fairly easy-to-read JSON file. Because it’s easy to understand, many team members can leverage it—including non-technical folks if necessary. JSON files allow teams to upload via Git and take advantage of its audit logs with every change made.

Database tables also have their advantages. App settings stored in a table can usually only be changed with admin database permissions, ensuring accountability and reducing the risk of a misconfigured value. Because it’s a table, user segmentation can be slightly easier if you leverage the relational database. You’ll also know exactly where to find all flags and their states, as the app settings act as a single source of truth for the flags and their values.

A homegrown feature flag management tool may work well indefinitely. However, it’s only a matter of time before other teams become more familiar with feature flags and their benefits. Usage grows and becomes more standardized. 

This is an inflection point. Internal executives may start to push to formalize and centralize feature flag usage across Dev and Ops teams. The homegrown system must scale to include more users across large teams or entire organizations—and this is where the challenges typically begin. The organization must decide whether they want to invest heavily in their own internal system or use an external platform. It must weigh concerns around security, infrastructure, governance and visibility. This decision will affect developers’ usage of flags, and by extension, the velocity of software delivery.

If you have the resources to scale your own feature flag solution, it’s important to consider not only what the pain point is today, but potential use cases that may come up down the line. This will help you outline the necessary architecture. For example, the minimum viable product for a homegrown solution is often built around a single tech stack. What happens when a new set of languages is added? You will need to form an upgrade strategy for new languages and integrations to come. 

Planning for the future is tough, however. Not every team may be in a state to customize a tool themselves—and if this is the case, it often makes sense to opt for an external feature flag management solution. Ideally, if companies are successful with growing their self-built system or using an external platform, they can continue to scale flags in their organization and make them a cornerstone of their CI/CD toolchain.

To learn more about how feature flag-driven development can transform software delivery in your organization, download “The Ultimate Feature Flag Guide.”