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.
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.
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.
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.
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.
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.
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.
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.