Feature Flags for the Non-Developer

If you’re a non-developer working in the tech world, you may have encountered the phrase “explain like I’m five” or “ELI5 - it’s a request to get a layperson’s understanding of a certain concept. When I need to learn about a technical term that’s new to me, sometimes I’ll Google the term along with the phrase “explain like I’m five,” then read through a few posts to make sure I’m on the right track. 

If you’re a product manager or director at a software company, you need to understand how your application is built and the work that goes into each stage. (Otherwise, you may find yourself making impossible promises to stakeholders and getting the engineering team peeved at you.) Feature flags can be an important part of the software development process, especially if your application is complex. What about those that don’t have a technical background? If you are in sales, marketing or customer success, you may find yourself getting lost in these explanations. (Booleans? What?)

There’s a simple answer and a complex answer to the question, “What are feature flags?” This article is an attempt at the simple answer, in the spirit of “explain like I’m five.” (Of course, this imaginary five-year-old would need to understand what software is—it’s an inexact metaphor, but a useful one.) For a deeper dive on feature flags, check out our eBook, The Ultimate Feature Flag Guide.

Writing software is hard, but the actual code is only the beginning. People who write software need to collaborate with each other to make sure that every part of the application plays nicely with all the other parts. They need to make sure that the software doesn’t lose the company money—and ideally, that it makes money. They need to make sure that others who use the software aren’t put at risk from a security perspective, and that they like using it. 

People who write software are constantly tweaking it to make sure that all of these goals are being met and to find ways to improve it even more. (Just look at how often your Facebook timeline changes from day to day.) When they make tweaks, they need to know that their changes won’t interact with existing code in unexpected ways or that users are disturbed by those changes. So they test the new code as much as possible before it reaches most people who use the software. When things go wrong—as things inevitably will—they “roll back” or remove the changes and try to figure out why the issues happened. 

Also, don’t forget that different teams (who may or may not communicate with each other) are making tweaks all the time. How do they know which tweaks caused which issues? How can they test a new improvement to learn whether or not people actually like it? How can they get all of this accomplished quickly, so they don’t hold up future changes? 

This is where feature flags become really useful.

A feature flag (also known as a feature toggle or flipper) is a way to change what your software can do without changing and re-deploying your code. Re-deploying code is a slow and risky process. Feature flags help your software team make changes quickly—and course-correct quickly if necessary. The team can simply “turn on” and “turn off” different chunks of code, making it much easier to revert to previous versions or even test certain features by only “turning on” the code for specific groups of people.

Feature flags help out your software team in ways that might not be immediately obvious to non-technical people like us. With feature flags, the team can accomplish all sorts of things like:

• Dealing with technical risks (software bugs and so on) separately than user-related risks (users might hate new features), allowing for more granular controls

• Testing features on a small group of users before rolling out to a wider group (similar to a canary launch, but better—with more capabilities for fine-tuning your test groups)

• Experimenting with new features by seeing how real people react to different versions (one common way of doing this is the A/B test, in which two similar groups of users receive slightly different copies of the same feature and the team measures how they respond)

• Executing a “kill switch” to turn off a feature for all users, which comes in handy when the team finds code that causes problems—or even when a feature has reached the end of its life

• Provisioning, or giving teams like sales and customer success more say over the features that matter to their customers, helps them respond to requests faster. It also saves the software team’s time from being sunk into administrative tasks for which they don’t have background knowledge

Feature flags can also assist the software team with work that isn’t directly tied to the product, like database migrations—which are famously nerve-wracking to manage. Using feature flags for these migrations helps your software team test the new system with as few disruptions as possible.  

Bottom line: feature flags make the lives of people in technical roles much easier.

Yes, you can have too much of a good thing. Most feature flags have an expiration date. Your software team needs to track their feature flags and delete them once they’ve performed the functions that necessitated them in the first place. Even if a feature flag remains turned on or off forever, it’s a chunk of code in the system that may not serve a specific purpose after the testing phase is over. Non-useful code like this is called technical debt and it can add up quickly if your software team isn’t careful. Every little piece of code in the system that isn’t tied to a specific purpose increases the likelihood that some of it could interact badly with other pieces of code in the future. 

Luckily, your software team doesn’t have to keep spreadsheets of their feature flags and delete each one by hand. Third-party tools like CloudBees Feature Management exist to automate the tracking process and minimize technical debt. 

Your software team can get their work done more efficiently by using feature flags to make changes without taking down the entire application. For you, this pays off in lowered risk and happier customers.

If you’d like to see how CloudBees Feature Management stacks up against their competitors, check out the CloudBees Feature Management Comparison Matrix.