In the previous step, we learned about progressive exposure. In this next activity, our first step will focus on hypothesis-driven development.

Once a feature is cleanly encapsulated, you can use it for hypothesis-driven development, as Microsoft Yammer does. If you want to know whether a feature helped with engagement or lifted revenue, feature flags allow you to tie back real metrics to code. After knowing the impact of your feature, you can switch the feature on (or off) for all users.

Feature flags are also effective for long-term access level control. If you have a feature that only advanced users should access, you can use a feature to provide a different experience for novices than for power users. You can use feature flags to control localisation, or you can also block an entire country if a feature shouldn’t be available there.

The Visual Studio Team Services LaunchDarkly extension enables feature flags for your releases.

Let’s move onto your CloudSwyft Hands-On Lab number 5, where we will test hypothesis-driven development.

Join the discussion

Could you suggest an alternative strategy to Feature Flags? How does your team currently handle situations where a need to split the development arises?

Use the discussion section below and let us know your thoughts. Try to respond to at least one other post and once you’re happy with your contribution, click the Mark as complete button to check the step off, then you can move to the next step.