Digital transformation is making companies more software-dependent than they’ve ever been. As analog products become digital and manual processes are superseded by their automated or machine-assisted equivalents, organizations are building more apps at the core and edge to compete more effectively. One way of hedging bets in an organization’s favor is using feature flagging to determine what is and is not translating to business value. 

Of course, feature flagging isn’t a new concept for developers, but the thought processes around it and its usage are evolving.

“I think the major change is that people realize that instead of being the exception to how engineering works where they’re using feature flags because they have a high-risk feature or they’re not quite sure how it’s going to work, now they’re looking at it as like maybe that’s how we should manage things all the time,” said Chris Condo, senior analyst at Forrester. 

What’s new about feature flagging
Feature experimentation platforms tend to support a range of methods that may include feature flagging, A/B testing, and canary and blue-green deployments. The platforms also reflect the shrinking nature of what’s being released with some platforms supporting increments as small as a code path.

Interestingly, the users of such platforms are evolving to include not only developers and DevOps teams, but product managers, designers, and even line-of-business users. Who can access feature flags depends on the platform selected and the customer’s culture and practices.

“The needs of the product manager, the developer, the designer and the analyst come together in this world,” said Jon Noronha, senior director of product at Optimizely. “Increasingly, [developers] are collaborating directly with their product manager or with the data scientist that might be assigned to their team or going to a designer to answer certain questions upfront of a project that they might not have even asked before.”

Apparently, the collaboration is having some interesting side effects, like developers telling their product managers they want agreement on success metrics before they start writing code. That’s a stark contrast to the traditional way of working in which the product manager tells developers what features to build, and then developers build them. Instead, it’s becoming more of a collaborative effort in which goals are collaboratively defined.

“I think a lot of different functions now can benefit from experimentation. Obviously, marketing has played a part in optimization but also thinking of the HR department in your company. Can they test their job opening pages? How can they benefit from experimentation? Are they getting the right candidates in?” said Sophie Harpur, product manager at Split.io. “I think it kind of can go across the board, so making it accessible to everyone across the org.”

Feature flagging has been a developer concept historically. Product managers haven’t been able to access anything or change anything themselves. Similarly, a salesperson couldn’t turn a feature on or off for a prospect that wants to try something in beta.

“If you can only change things by playing around with command-line tools or editing values in the database, it’s kind of an archaic and error-prone process even for developers, so they’re not likely to use it all that often,” said John Kodumal, CTO and co-founder of LaunchDarkly. “It’s a niche technique you’re only going to use when you absolutely have to do it.”

Without a feature experimentation platform, a product manager usually files a Jira ticket. With a feature management platform, the same product manager can access the feature flags they need and modify them. 

Driving positive business impacts
As more companies adopt a quantitative mindset, they’re compelled to measure the effectiveness of individual features through experimentation. Toward that end, organizations are monitoring technical metrics such as feature and API performance, and business metrics such as increasing customer engagement.

“Restaurants, airlines, and car manufacturers realize that in order to compete in 2019, they need to have the best software on the market,” said Optimizely’s Noronha. “They need to bring that in-house, build it themselves and adopt some of the best practices that the Silicon Valley elite use. Those companies use feature flagging pervasively throughout their processes.”

There are also some organizational dynamics that are fueling the demand for feature flagging, including CEOs who are questioning the value of software investments and the sought-after, recently acquired talent that wonders why the code base is such as mess and how anyone manages to get work done.

“I think those guys are there to make forward progress on both the infrastructure and on the value of the work,” said Optimizely’s Noronha. “Feature flags are often the first step in just getting your infrastructure under control. You fence off certain areas of your products where you can make progress on them independently. One customer [called this] ‘containing the blast radius of new changes,’ which I really liked.”

Feature flags also allow developers to change the narrative about their own success metrics. Instead of telling the CEO they built 30 new features last quarter, they can show how much the new features increased the value delivered to the customer, which is what the CEO cares more about. Demonstrating positive business impact as verified by data also tends to lower the barriers to future funding.

Importantly, feature flagging enables companies to test small changes and detect if they’re impacting the metrics that the organization cares most about.

“A lot of the kind of large enterprise companies are all moving in that direction,” said Split’s Harpur. ” It’s thinking about that transformation of organizations turning into digital companies and then turning into experimentation companies.”

Experimentation allows organizations to move faster and invest in the right things. The overarching benefit is staying ahead of the curve. 

“To be data-driven is to let your [users] tell you what they like rather than having the highest paid person tell you what you should be doing,” said Lizzie Eardley, senior data scientist at Split.io.

Where canary and blue-green releases fit in
Feature flagging can be done in place of canary and blue-green releases or they can be implemented as complementary practices, depending on the goal.

In a canary release, a change is pushed out to a small group of users to see how it performs. If it performs well, then it’s rolled out to more users. Feature flagging allows a more precise selection of users, down to individual users.

“Typically, what happens in a canary release is that particular code is put out there and anybody can get access to it. It’s just that it’s only available on a certain set of systems and then you can measure whether or not it’s ready for further deployment,” said Forrester’s Condo. “If you’re putting out a brand new product and during that canary release you only have alpha users and then maybe beta users and then you decide it’s actually performing well, let’s spread it out. If it’s just a microservice that’s been updated, a small piece of your website that’s changed or has a new feature, maybe use a feature flag and measure the impact. I think there’s the right tool for the right situation.”

Blue-green deployments involve identical hardware environments, one of which runs live software while the other remains idle. New code is deployed to the idle environment and tested. Users are then switched over to the formerly idle servers that now run the updated software, and the process continues.

“With blue green-deployments you can flip back and forth between one version and a newly launched version, but it’s just two versions, really, because nobody scales blue-green beyond that,” said LaunchDarkly’s Kodumal. “Feature flagging allows you to do things in a more fine-grained way, so if you have 20 different developers committing and releasing at the same time you have the granularity to say these things are not risky, so let’s turn them on and those other things are risky, so let’s turn them off. And at deploy time, with blue-green, it’s still a very binary decision: either all of the new code is being deployed or not.”

With feature flagging, the level of granularity can be as fine as a code path, so it’s possible to decide whether an individual code path should be executed. 

On the other hand, not everything needs to be feature-flagged. For example, a simple bug fix may not warrant feature flag overhead. If it’s an infrastructure configuration change, a blue-green release may make more sense than a feature flag.

Another type of testing that tends to be supported by feature experimentation platforms is A/B testing in which companies are experimenting with two different shopping cart flows, or two different site designs, to determine which is most successful, statistically speaking. 

“Feature flagging and A/B testing have gone down parallel tracks,” said Optimizely’s Noronha. “You’ve had development teams implementing feature flags for the purpose of continuous integration and deployment, and product analytics where there’s been this evolution of A/B testing from being something that just the biggest tech companies do to something that’s much more mainstream. Those practices have converged into something that a combined product and engineering team does to monitor their progress.”

In short, feature experimentation isn’t one thing. There are different ways to experiment, each of which has its benefits and drawbacks, depending on the use case.

Using feature flags for entitlements
Feature flags can be used as a means of controlling access rights based on a subscription. Instead of having huge buckets into which customers fall, such as Basic, Professional, or Enterprise product levels, feature flagging can allow individually customized products. 

“You’re seeing companies take feature flagging one step further,” said Forrester’s Condo. “They’re saying, ‘Hey, instead of managing multiple levels of licenses and people having to install keys or do these complicated setups, we can simply put them in different demographic [categories] and turn features on or off or give them the ability to turn features on or off and let them decide what level of subscription they should have.”

LaunchDarkly uses its own platform itself for many things, including changing the rate limits of its API based on the customer or characteristics of their traffic. That way, the company can customize the flow based on an individual customer’s requirements.

“We can impact not only the way people develop software, but how businesses run their software because the cost of customization is lower,” said LaunchDarkly’s Kodumal. “Being able to release specific versions to specific customers is incredibly powerful.”