Using feature flags in your app release management strategy

We recently discussed feature flagging in depth with Edith, who has some interesting things to say to developers interesting in keeping their apps glitch-free, and more engaging to their users.

ADM: How has feature flagging changed the way developer and engineering teams build products? Is it a widely used method or is it still in the nascent stages?

Harbaugh: Feature flags haven’t changed the way products are currently developed and released as much as consumer expectations have. If you look at the mid 1990s, software companies like Microsoft were releasing new operating system updates on an annual basis. This meant each release was a monolithic rollout that could be buggy and if it didn’t work, would end up being a huge financial and brand flop.

It’s not like this anymore. For example, in 2005, Facebook helped pioneer a new way of releasing features and keeping the user experience fresh, engaging, and new. Having learned from its news feed update debacle in 2006, it set the tone for releasing new features and updates on an almost continual basis. Facebook’s engineering team, in large part, set the cadence of how and when consumers expect software updates and new features to become available.

Now, in 2018, customers expect instantaneous updates and fixes. In-house teams can’t keep up with these expectations unless they’re continuously testing new features and have deep insight and control into the entire process. Feature flags aid in this process.

ADM: How do feature flags aid in release management?

Harbaugh: Feature flags, also called feature toggles or feature flippers, allow development teams to achieve a faster time-to-market for each feature, but with less risk. Feature flags allow developer teams to change system behavior without changing the code and, more importantly, without impacting the user experience.

Developers can wrap each new feature with a flag and that allows them to control which users can see it. This means new features can be deployed, but hidden from users until the company decides to it roll out. If the code is buggy or users revolt, developers can pinpoint where the issue is and flip the “kill switch” for that specific feature (like an “oops” button for developers).

Feature flag-driven development allows teams to manage every phase of planning, building, testing, launching, and collecting user feedback. This means increased control over the entire release process.

ADM: What level of experience do developer or engineering teams need to use feature flags?

Harbaugh: Developer teams of all experience levels can use feature flags to create better products. Any member of your company’s team that is invested in managing how and when customers interact with your features should understand the value of feature flags; which means almost everyone in the product development process.

For example, the developer team would use a feature management platform for continuous delivery, database migrations, multi-site management, and testing in production. The operations team would use them for feature kill switches and safety valves, the product team would use them for dark launches and ABn testing. The marketing team uses them for betas and scheduled releases, and the sales team would use it for entitlements, POC previews, and upsells.

LaunchDarkly’s feature management dashboard makes controlling features as easy as flipping a switch, meaning any stakeholder, regardless of their familiarity with code, can use it intuitively.

ADM: Do you think hypothesis driven development is a value held by engineering and developer teams across the tech industry? Are there any brands that are running exceptional testing programs?

Harbaugh: Hypothesis-driven development should be widely practiced, but it hasn’t been fully adopted and integrated into product development culture yet. I think once teams start using feature flags in everything they do, it becomes obvious that features can and should be constantly tested and tweaked. Once that realization hits, there is a natural transition to hypothesis-driven development since any new feature idea wrapped in a flag can be easily validated or killed.

Netflix is really good at testing their features and providing constant, almost unnoticeable updates.

ADM: From a developer’s standpoint, how has the process of testing new features changed over the past 5-10 years?

Harbaugh: Testing features 10 years ago was pure “push and pray.” Because product release timelines were so long and spread out, any new features or updates were major, since they would involve all the technological progress of the past year or so. These very noticeable sudden changes in a company’s product often caused unhappy users, but there wasn’t a good way to test or remove certain features with certain users, so the update would either have to be killed for the entire user base, or permanent (at least until the next update a year later). As product release timelines have grown shorter and closer together over recent years, it’s become much easier to test new features.

ADM: Who is driving the need for improved testing processes? Consumers, or engineering teams?

Harbaugh: This is a “chicken or the egg?” scenario. Engineering teams are iterating more quickly and releasing new features not on a daily basis, but on a minute-by-minute basis. Because of this, software is being improved in tiny increments, almost to the point where users don’t notice the individual changes as they’re implemented, they just know that the experience is smoother, better, or faster.

Now that consumers are accustomed to gradual, almost invisible (but positive) changes to their experience, they expect these improvements to happen continuously. Engineering teams must continue to deliver updated software on a near constant basis because users now demand it.

ADM: How is the user experience impacted when apps glitch or don’t perform well?

Harbaugh: Users expect their software or apps to work right the first time, every time. With each glitch or 404 error, users are more likely to abandon your app and switch to a competitor. For example, if Uber is glitching and you can’t get picked up within 3 minutes, you’ll likely switch to Lyft, expecting not only a quick ride, but a smoother experience. And, if Lyft continues to deliver on a smoother, more reliable user experience, your brand loyalties as a consumer shift. Once a consumer decides where their brand loyalty lies, it’s incredibly hard to change their mind.

ADM: Why do you see feature management as a category on its own?

Harbaugh: Feature management affects the entire team. If any function of your job impacts the user experience, then managing how, when, and even why certain users interact with a feature is your responsibility. This extends across sales, marketing, development, engineering and product; it’s not just a developer’s concern or a marketer’s concern. 

About Edith Harbaugh

Edith has more than 10 years of experience in product, engineering and marketing with both consumer and enterprise startups. Most recently she was Product Director at TripIt and Concur. She holds two patents in deployment from her time in engineering at Vignette. Edith has given talks on feature flag management at Microsoft Build, NDC Sydney, GlueCon, and DevOps West; and is a contributing writer to DZone, DevOps.com, and ReadWriteWeb. She cohosts the “To Be Continuous” Podcast with Paul Biggar, CircleCI founder. Edith earned a BS in Engineering from Harvey Mudd College and a degree in Economics from Pomona College. She enjoys trail running distances up to 100 miles.