Feature flags have been turning a lot of heads in the world of DevOps these days. So, what better person to bring on the DevOps Radio podcast than Pete Hodgson, a British-born independent software delivery consultant who specializes in helping startup teams improve their engineering practices and technical architecture.
Pete spent six years as a consultant with the agile-development pioneer ThoughtWorks, leading technical practices for its West Coast business. He also did several stints as a tech lead for a handful of San Francisco startups.
In 2017, Pete wrote an article about feature flags after becoming frustrated that a lot of his clients were using the feature flagging term the wrong way. Even though feature flagging was a very well-established practice in companies like Flickr, Etsy and a handful of other pioneering organizations, “there wasn’t a good definition on the internet,” Pete recalls.
So, what are feature flags? They are “fundamentally the ability to choose at runtime between multiple code paths,” Pete says. “At runtime, we can say, ‘Should we do A or B? Should we do X or Y?’" For software organizations, feature flags mean they can release new application features into production and make them available to specific users without restarting the app or deploying new code.
Looking ahead, Pete sees companies using feature flags in a growing number of applications. “A common use case would be when you’re working on some new feature but it's not ready for prime time yet,” he says. “So, you can hide that half-finished feature behind a feature flag.”
Feature flags are a great way to do “canary releases” that allow engineers to “turn on” features for a small portion of their users and get their thumbs-up before rolling out the app to more customers.
Product managers could also use feature flags to try out different versions of a product by releasing them to different audience segments to see which version is more popular—and profitable. Such A/B testing techniques using feature flags are attracting the attention of companies that are embracing a more scientific, data-driven approach to product management.
Pete says that adopting and scaling feature flags is driving a cultural shift in organizations that use progressive delivery and a hypothesis-driven approach to software development. “Continuous delivery is really hard to do without feature flags,” Pete says. In a world that is moving faster all the time, “there's a clear competitive advantage to continuous delivery.”
Engineers are slowly getting used to the idea of deploying “half-finished” code to production, Pete says. Initially, “people will think, ‘That sounds terrible.’ Then they try it, and say, ‘Oh, it's not as bad as I thought.’"
As feature flags become part of your code base, changing them becomes as simple as making a code change. “It flows through your environments the same,” Pete explains. “It gets QA-ed the same, it gets reviewed by security the same and you can roll it back the same. All that happens for free if you use that pipeline that you've spent so much time building.”
How do you get started becoming a “feature-first” organization? “My general advice is to start small; start simple,” Pete says. “Just take one of the features that you're working on and put it behind a toggle. Make sure that the first one you do is an easy one.” Avoid starting with a “fancy all-encompassing system” until you’re ready.
The Future of Feature Flags
While it’s a good bet that feature flags are the wave of the future, Pete cautions against building your own feature-flagging network. They are “fun to implement,” Pete says, but “they can be like the tip of an iceberg with massive amounts of functionality lurking under the surface.” In practice, the way you do your feature flagging offers little competitive advantage, he says. “You should just find an open-source tool or a commercial product to do that.”
Organizations will need to carefully manage their feature flags so they don’t multiply out of control, leading to “flag debt.” Pete says retiring old feature flags is among the most common burdens organizations face with the technology. And if you don’t stay on top of old flags, they can sometimes come back to bite you. That’s what happened at Knight Capital, an investment company that failed to keep tabs on one of its feature flags it deployed years earlier, accidentally triggering half a billion dollars in trading losses.
This is when having an enterprise feature flag management tool could make a difference, helping companies keep flags in check and identify which ones should be retired and removed.
To listen to more of the conversation with Pete Hodgson, tune into Episode 98 of DevOps Radio.