When is it time to move to feature flag software?

Olga Diaz

October 12, 2023

Teams can get quite far with feature flags on their own. Many feature flags are simple booleans that can be set up without a dedicated tool. Developers realise early on that they need to disable parts of the code, and will create feature flags in the database or using code configuration. Teams will even write code to turn features on/off for specific users or segments.

There’s a tipping point, though, where managing the feature flags in-house becomes unsustainable. A few warning signs that you’re reaching this point are:

Needing feature flags to propagate across a microservice architecture
Realising that you’re tired of not knowing who changed what when
Getting tired of product owners or business people asking you to change the flag for them or activate a flag for a user

We spoke to Olga Diaz, a Senior Full Stack Software Engineer who has helped development teams at multiple companies release more confidently with feature flags. She shares her thoughts on knowing when it's time to bring in feature flag software, and some tips for setting your teams up.

When is it time to move from self-hosting or homegrown feature flags to a dedicated feature flag management tool?

1. When you need role-based access control and auditing

Teams often kick off their projects by implementing their own solutions, initially utilising code for feature flagging that operates within the confines of the database, using it as a source of truth. This approach necessitates direct manipulation of the production database, involving operations like inserts and updates, in order to selectively release features to specific clients.

Unfortunately, this method typically lacks crucial elements like historical tracking, observability, and access control. To address these shortcomings, a dedicated feature flagging tool becomes imperative. For instance, if you need comprehensive user permission management to keep track of who modified specific flags and when—primarily for auditing purposes—a specialised tool is essential.

2. Testing in Production

In a multi-environment setup, situations often crop up where database passwords or API credentials need to be configured for each environment. Developers may diligently write and test their code up to the acceptance stage but often overlook the crucial step of setting up configurations for the production environment.

When deploying the application in a production environment, this oversight can result in feature malfunctions. However, when employing feature flagging, which enables the activation of specific features based on defined criteria (such as particular usernames, user groups, or geographic locations), you gain the capability to conduct real-time testing within the production environment before making the feature available to the entire customer base. Should any issues emerge during this controlled release, you can promptly identify and address them, minimising any potential negative impact.

While it is technically possible to manage this process manually and develop custom software to handle such targeted and segmented behaviour, feature flag software greatly streamlines the management, segmentation, and precise control of feature releases.

3. Coordinated releases

Imagine you have six distinct Scrum teams collaborating on the development of a single website.

To optimise the development process, you decide to divide the front end into micro-front ends and the back end into microservices. This approach necessitates extensive coordination among the teams to ensure that specific feature flags are active simultaneously throughout the entire user interface. Managing this level of synchronisation and coordination becomes immensely challenging without a feature flag management tool.

It's essential to note that the scenario described earlier pertains to a coordinated release (of a feature implemented in a distributed system), not a coordinated deployment. In some organisations, coordinated deployments are still the norm. However, for those looking to transition from this approach to embrace continuous delivery or even continuous deployment, the importance of a feature flag management system cannot be overstated. Such a system becomes indispensable in enabling a smooth shift toward more agile and efficient software development practices.‍

4. Developing mobile applications

If you're developing a mobile application and you encounter a problem upon release, the process of pushing a new version may take days (or longer). During this time, the bug remains unfixed and can negatively impact the user experience. In a context like wealth management where you serve private clients, such issues can tarnish the company’s reputation and have serious consequences.

This situation often motivates development teams to implement feature flags and adopt the principle of "graceful degradation". Feature flags empower you to not only test new features in a production environment but also provide the flexibility to disable a feature if it proves to be buggy. Moreover, you can decide whether to leave it visible for those users who have already seen the feature or display maintenance screens with custom date ranges to communicate temporary service interruptions.

Simultaneously, you can maintain development momentum through a trunk-based development approach, enabling prompt problem resolution and ensuring a positive user experience, thereby upholding client satisfaction.

5. Enabling product owners

When you have a need to enable a specific feature for a particular client or set of clients, feature flag management comes to the rescue. With this system in place, a product owner gains the ability to test features in a production environment and easily switch them on and off without requiring engineers to make manual changes to configuration files or databases. A centralised feature management tool empowers product owners by the use of a simple UI, reducing their reliance on engineers for feature flag implementation.

Furthermore, from a developer's perspective, this system provides valuable visibility into feature activation and deactivation, allowing for real-time observation of feature performance and user interactions.

While you might be tempted to weigh up building a feature flag management system in-house, it's important to remember that your primary focus is building products, not feature flag management.

This is typically the juncture where it makes sense to explore the market for existing tools that meet your specific requirements, thus saving time and resources while ensuring effective feature flag management.

Checking your requirements when choosing feature flagging software

When looking at your needs, ask questions about things like:

Deployment options - Do you need your feature flag system to be deployed and managed by your own IT or be a SaaS?
Sensitive data - Do you need to make sure the tool doesn’t have access to your flag and customer data?
Client vs. server-side evaluation - e.g. Do you want feature flags to be evaluated on the server side for security and privacy, or does client-side evaluation suffice?
Integrations - How well does it work with other tools and databases you already use?‍
Migration support - How easy is it to switch systems? How do they support migrations—and support you ongoing?

Best practices for migrating from homegrown or self-hosted feature flags

When you’ve decided to move to a dedicated tool and have chosen a product like Flagsmith, the next step is to create a process for adoption and deployment. You can’t just deploy it and expect the team to use it. A few things that can help:

Team training and documentation - Set up technical talks about things like best practices, what can go wrong if you don’t set defaults, how to set up A/B tests, how to debug and know which features were enabled for which users, and so on. Educate everyone in the team (not just engineers), and make sure they know how to integrate with the other tools in their stack.
Find a provider who can help with training - Some feature flag providers (like Flagsmith) will help with setup, training your teams on feature flag best practices, etc. This helps a lot!
Start small - Consider configuring the tool for a small team before rolling out to a wider user base and other teams across the company. This way you can learn and iterate as you go.
Think about best practices for your company specifically - Are you a startup that can onboard quickly? Are you in a data-sensitive industry that needs to be cognizant of privacy and user data? There are likely best practices that will apply to your individual use case.

Conclusion

If you’re feeling tired of not knowing who changed what and when, or you’re sinking time into helping product change or activate feature flags, it might be time to move to dedicated feature flag software. This is a big decision, but there are a lot of signs and best practices you can keep in mind as you walk through the build vs. buy analysis, and moving to a dedicated tool can ultimately make deploying and releasing feel much less risky and easier to manage.

Just like Jez Humble says in his “Continuous Delivery” book: “if it hurts, do it more often, and bring the pain forward.”

When is it time to move to feature flag software?

Subscribe