Want a quick email when a new article is published? Subscribe
Feature Flags: Why Safety may be the Ultimate Performance Enhancer
In many boardrooms, there is a lingering fear that moving faster in software development inevitably leads to breaking more things. We’ve been conditioned to believe that speed and stability are two ends of a see-saw: if one goes up, the other must come down.
This is a false dichotomy. In reality, the most productive engineering teams I’ve led aren’t the ones who work longer hours or write “better” code. It is, in significant part, the ones who have decoupled the act of deploying code from the act of releasing a feature.
The tool that makes this possible is the humble feature flag.
The cost of caution
A few years back, I stepped into a situation where a squad had been sitting on a major update for nearly three months. The code was finished. The logic was sound. However, the team was paralysed by the fear of a big bang release. They knew that if a single bug had slipped through, it would affect every user simultaneously. The risk to the business felt too high, so they did nothing. Meanwhile the code grew stale, merging was a nightmare and nobody wanted to put themselves on the line and release it.
To break the deadlock, we had to get creative. We didn’t have a feature flag system yet, so I asked them to create a “shadow system.” They pointed a secondary environment at the live database and gave the URL to exactly one user to test. It was clunky, but it proved the point. Once that user gave the green light, the team’s confidence surged. They implemented a proper commercial feature flag system immediately after and haven’t looked back since.
Moving from “Big Bang” to “Quiet Ripple”
Feature flags allow you to wrap new code in a conditional IF statement. You can push that code to your live environment, but it remains dormant. It’s there, but it’s invisible.
This changes the game in three specific ways:
Risk Mitigation: If a new feature causes a memory leak or a UI glitch, you don’t need to roll back the entire deployment or wait for a hotfix. You simply flip a switch in a dashboard. The feature disappears for users, but the rest of the application stays live. When you’re managing an incident, this can be the difference between a five-minute fix and a three-hour war room.
Real-World Feedback: You can release a feature to 1% of your users, or just your internal staff. This allows you to gather telemetry and feedback in a live environment without betting the farm on a single release.
Continuous Integration: Developers can merge their work into the main codebase daily rather than keeping long-lived branches open for weeks. This prevents the merge issues that often derails projects in their final stages.
The Buy vs. Build trap
Engineers love to build things. It’s in their nature. When I suggest feature flags, the first instinct of a technical team is often to build a bespoke toggle system in-house.
Resist this.
Feature flagging is a solved problem. Commercial platforms provide the auditing, targeting, and permissions that your team doesn’t have time to build from scratch. Your engineers should be focused on your unique value proposition, not building infrastructure that can be bought for a monthly subscription. Not only that, but good feature flag systems have all kinds of clever tricks. They can turn conditional turn features on, based on user actions. They can deliver the code only to users with a particular browser or do a guarded rollout which progressively increases the number of users on the new feature whilst monitoring a metric for regressions (bugs).
For the CEO
If you feel like your engineering team has slowed to a crawl, it might not be a talent issue. It might be a safety issue.
Ask your CTO: “What happens if we find a critical bug in a new feature five minutes after launch? Do we have to roll back the entire release, or can we just turn that one feature off?”
If the answer involves a stressful, all-hands-on-deck rollback, you’re carrying more operational risk than you need to. Feature flags aren’t just a coding thing, they are a business insurance policy that allows your teams to move faster and stay safe.
Comments
Leave a Comment
All comments are moderated and may take a short while to appear.
Loading comments...