Engineering leaders want their teams shipping constantly and deploying changes as fast as possible, but they only want those changes to launch when complete, so they can respond to customer feedback and production issues in real time. Feature flags enable users to manage feature releases by toggling features on and off, which changes the software’s functionality without deploying new code. Feature flags can also prevent untested work, premature features, or features only intended for a select user base to launch; however, the culture and process surrounding how the team uses flags must support these outcomes.
While the great thing about modern trunk-based development based on feature flags is that you can safely commit and deploy incomplete features to a production environment without risk, sometimes, management just hears: “feature flags encourage you to commit broken code and throw things onto production before they’re ready!” We’ve met with more than one engineering leader who thinks feature flags might accidentally exacerbate, rather than solve, bad engineering habits that have taken root. But it’s more nuanced than that. In this blog, we’ll discuss the importance of incorporating feature flags as a cultural shift in your development teams and some common misconceptions about their implementation.
We are fond of saying that feature flags are a way of working as much as they are a tool. Just like how continuous integration and delivery (CI/CD) permanently changes how an engineering team operates, so do feature flags. With flags, teams collaborate more, merge and test code more often, deploy faster, and get features out the door quicker. This efficiency – which increases the operating cadence for a team – naturally encourages more cross-functional collaboration and less silo’ing.
However, the role of feature flag management in the software delivery lifecycle (SDLC) is often misunderstood. Feature flags are only one part of your engineering culture. While they’re critical for teams to be able to get into a rapid, high velocity, data-informed development style, they are not a substitute for other checks and balances that have to be in place for your software to be stable and reliable. This is one of several common misunderstandings about what feature flags can (and can’t) do.
Let’s dive into four common misconceptions about feature flags and the truth behind them.
Reality: This is only true if your culture itself doesn’t celebrate proper testing. Feature flags, in fact, make it easier to help teams focus on quality by letting teams release incrementally and make progress day-to-day. It is true, though, that in a culture that lacks discipline with testing, more flag combinations can create more risk. However, when developers are expected to test their code in order to get production sign off, feature flags don’t actually introduce any new risk vector at all. Feature flags aren’t a substitute for testing – any code path that can be lit up with a flag should also be tested as usual.
Reality: This is fair, and it’s the downside to the super useful benefit of “it’s easy to make changes quickly in production.” At Harness, we’ve built pipelines, governance policies and robust role-based access controls (RBAC) to help teams control who can change flags, when, and what needs to happen when they do change. Teams that leverage proper controls can both move quickly and safely.
Reality: It is in fact often the opposite, feature flags provide clarity around technical debt and what is enabled in production. Similar to “what can’t be measured can’t be managed,” feature flags bring a level of visibility to your releases and to what is currently configured, so you can keep track of it over time. This visibility identifies any stale code that should be deprecated, and you can always find what is configured in any given environment and when it may have changed.
Reality: While we talk about how feature flags help teams achieve high-velocity best practices all the time, this may create the impression that feature flags are a crutch, but not something you need once your team evolves. In reality, without separating release from deploy, there is no way to maintain a high velocity with a low level of risk. Your development cycle will always depend on your deployment cycle if that’s how your team launches new features or rolls back changes, and deployments will always be inherently more risky and less efficient.
Here’s a thought exercise: what do you do when your organization, applications, and deployments keep getting larger, slower, and riskier? The answer may be obvious, but it’s to find ways to move faster and reduce risk simultaneously. Feature flags in particular are the technology choice made by organizations facing these limitations from their CI/CD implementations. Feature flags as a technology help teams to move quickly and safely, which is why it’s important to adopt the technology, not the bad practices.
Most teams see quality, reliability, testing efficiency, and reliability greatly increase after adopting feature flags. However, team culture and best practices are also where you need to drive change. By adopting a culture of responsible feature flag use and investing in the right processes and tools, engineering teams can unlock the full potential of feature flags to deliver high-quality software at high velocity.
If you’re looking to see how you can leverage feature flags safely and encourage good habits instead of these bad ones, you can learn more about how we do that with Harness Feature Flags. Request a demo or sign up to start using feature flags the right way today.
Enjoyed reading this blog post or have questions or feedback?
Share your thoughts by creating a new topic in the Harness community forum.