Feature experimentation platforms can help organizations deliver software faster because they are aware of expected and unexpected feature-related behavior sooner. As organizations continue to accelerate their release cycles, they continue to ship ever smaller amounts of code that should be experimented with, individually.
“It’s the next obvious step in continuous delivery [because] continuous delivery is all about shipping the smallest unit of change LaunchDarklypossible, which is an individual code path,” said John Kodumal, CTO and co-founder of . “Feature planning is fundamentally about that, and what that unlocks is pretty game-changing.”
RELATED CONTENT: Waving the flag for feature experimentation
Feature flagging also enables teams to work even more independently than they have been, which also tends to accelerate development.
“Customers using DVCS and feature branches have told us it was really expensive to take a long branch, merge that back into the mainline code base and deploy it because the two code branches diverged pretty quickly,” said Kodumal. “Integration time is extremely expensive.”
With feature flagging, teams can merge code and keep it turned off and then turn it on in an isolated environment, like a staging server or a developer’s production account, which also helps teams move faster and be more productive. However, “move faster” doesn’t necessarily equate to “move faster and break things.” Organizations need to take risk management into account, because the “value” they’re delivering isn’t as valuable as they think if it’s being delivered at the price of customer angst or the company’s reputation.
“Release velocity has gone up in many cases, but increasingly you see teams scratching their heads wondering about the actual value of all these launches,” said Jon Noronha, senior director of product at Optimizely. “People find themselves in ‘the feature factory’ where they’re shipping one thing after another, but uncertain about the actual [business] outcomes.”
Increasingly, businesses want to understand the value and outcomes of investments. Feature flagging helps.
“People want to be able to use feature flagging for all kinds of software, not just the web, desktop or mobile devices, but things like Amazon Fire Sticks or Roku boxes,” said LaunchDarkly’s Kodumal. “Whatever it is, the story’s the same: they need to deploy small units of code that have changed quickly across any networked piece of software.”
Speed does not trump quality
Digital experiences in all channels are constantly resetting customers’ expectations. While some organizations may deliver great experiences in one or more channels, they may fall short in others. Yet, from the customer perspective, the best example in any channel is the standard by which all others are measured.
“People expect the software they’re using on a day-to-day basis to be flawless and they don’t tolerate crashes they way the used to,” said Kodumal. “When we as consumers trust software companies to so much of our lives, it’s just not acceptable for the bank app to crash or for the banking app to be unavailable because the company needs three hours of downtime to upgrade the app.”
Feature flagging allows users to see and measure expected and unexpected impacts.
“Doing things in a data-driven way can [help you identify expected and unexpected impacts] quickly and allow you to reduce the number of customers that are affected,” said Sophie Harpur, product manager at Split.io. “You should have metrics tied to every feature release and make sure you’re detecting things that you’re not expecting.”
Another benefit of feature flagging is the ability to move beyond brain-dead minimal viable products (MVPs) to MVPs that enable customers to test-drive software on their own data.
“I can put out an MVP to a select set of alpha users who are maybe super users of my product and get their direct feedback. If I’m using a feature experimentation platform and you’re not, one of the problems you’re going to have is you’re going to have to deploy that code to a staging server, but users won’t be able to use it on their data because your software is quarantined on a separate set of servers,” said Chris Condo, senior analyst at Forrester. “Meanwhile, my users are testing my feature directly on their data. They can look at it, see how it works, try their complex queries or look at the data in different ways. I’ve lowered risk and I’ve increased my velocity because I know I can control the exposure of that feature.”