Building quality software requires finding ways to simplify the development process. Feature flags, also known as feature toggles, provide a simple way to improve software development. They are simple conditionals used to control code execution.
Most developers are acquainted with the concept intuitively. If you have used a true/false statement to make sure certain parts of your code were turned on or off during runtime, then you were basically using a feature flag or toggle.
These flags are excellent tools for risk mitigation. Even though the concept is simple, trying to implement them in a large-scale system can get complicated.
Naturally, the question arises, should you build or buy? There are viable options for both. Before diving into the complexity of choosing a path, let’s look at the value these flags provide.
Why are feature flags valuable?
Today software is developed and deployed in increments. The days of massive releases are over. The headaches of large-scale releases are hopefully behind us. Development managers use steady feature rollout to ensure a calm and safe development process.
Flags help in the following areas:
Development Speed
Developing multiple features in parallel is a common software practice. In order to avoid conflict, developers work in their respective feature branches. This process works well until it is time to merge.
Merging branches at different levels of development maturity can turn into a nightmare. It takes time and resources to clean or eliminate partially-developed features before shipping. It can slow down the overall development process.
Feature toggles or flags decouple features from each other. Instead of using branches, developers can use the toggles to turn off incomplete features from the product. Through simplifying the process, Feature flags speed up development.
Learn more about feature branches and feature flags.
Deployment Safety
Continuous integration and continuous delivery (CI/CD) help development teams deploy faster. Release maturity models dictate the level of automation. However, automation always has an associated risk factor. No automation is full-proof against catastrophic failure.
Feature flags can provide a safety net. The flags can be used to turn off harmful code until a solution is found. It can be even used to regulate experiences based on criteria like user preference or location. It gives a development team more power to control the software experience in the real-world.
Experimentation
In the old model, releases were held sacred. Feature rollout was homogenous for all users. Every user’s software experience was the same.
Today it’s possible to use flags to control the user experience through segmentation. It means experimenting with different business goals is easier. Using A/B testing, you can find out more about your customers. The experimentation can lead to a more satisfactory experience for your users and a more fulfilling creative experience for your developers.
Feature Customization
Some businesses are taking the idea of experimentation to the next level. They want to provide customized versions of their software to different segments of the population.
For example, customers who express interest in a particular feature of a software will get it with that feature turned on, while others will never know that feature even exists. Feature customization like this could become the norm in the future.
What are the challenges of a feature flag system?
There’s no doubt that your development and production team will benefit from having a feature flag system. You have two options: build or buy. You have to decide what option is best for you depending on your resources, organizational structure, and development process.
Building your own system gives you full control over all functionalities. It is great but it also has challenges:
Continuous Infrastructure and Maintenance Cost: You build it, you own it. It means developers, QA and management have to invest time and money to maintain and upgrade the system. The resources diverted to create, maintain and upgrade can take away the focus from your core business.
Lack of Advanced Functionalities: Internal flag systems are built for immediate needs. They are generally minimum viable products. They lack advanced features because of the associated cost. They would usually lack a good UI dashboard and would require engineers to operate.
Lack of Synergy: Maintaining a system that meets the need of worldwide teams require access control and auditing capabilities. Internal systems that don’t have these capabilities have a hard time creating synergy across the organization.
Uncertain and Unpredictable Requirements: Pivoting and changing requirements are common in the software industry. Building a flag system can be difficult in such an environment. Today’s essential custom flag system can become useless tomorrow. You'll be stuck with a dinosaur in the room. Moreover, it usually starts small with the R&D team, but then expands to more stakeholders such as product managers (for the purpose of experimentation), they would have totally new and different requirements.
Given the potential challenges, it is important to ask yourself the following questions before deciding to build a system:
Do I have the resources to spare from my core business to create a flag system?
How much am I willing to spend on maintenance of the system?
What hardware and software investment do I need to create the system?
Will I be able to scale my system both for other development teams but also PM's?
Will the flag system be compatible with my current production pipeline?
What is the long-term plan for the system?
Building a feature flag system
After answering the questions above, you will have a better idea of where you stand in terms of building the system. If you decide to build, you need to think about the following:
Dashboard: Your business needs to be able to visualize the process. It is not enough to document flags and expect the non-developers to figure it out on their own.
Permissions: In order to control the flags, you need to set up a system that can handle different levels of permission for different users. Your admins and your general users should be able to function side by side.
Analytics: Analytics can help determine how the flag system affects performance.
Reliability: Your feature flag system needs to be robust enough to support a production environment.
As you can see, building a feature flag system requires investment in time and human resources. Due to the complexity of building a system, you might consider purchasing a feature flagging management platform.
Buying a feature flag system
However, before you buy a system, you need to understand if it is going to be a good fit for your organization. You can run pilot projects to get a better idea of its viability. Here are a few other things to look for:
Ease-of-use: Feature Flagging systems come with an overhead, you want to make sure the system you choose helps your developers streamline the processes associated with adding/ managing and removing of flags.
Reliability: Ensure the system will not become a bottleneck through introducing its own problems and bugs into the development cycles.
Scalability: Find out if performance degrades under high-volume conditions.
Well-Documented: Good documentation can make the integration process easier.
Conclusion
Choosing to build or buy your feature toggle or flag system will depend on your business’s unique requirements and resources. Whether you choose to build or buy, you will benefit from understanding the value of a feature flag system. It will help make the decision process easier.
CloudBees Feature Management is a secure, scalable feature management platform that allows developers and software teams to accelerate mobile, web, and back-end development by giving them maximum control over their features in production. It enables developers to progressively deliver
features to users with confidence, in real-time.