The Life and Times of Feature Flags

A while ago, I had the opportunity to look closely at DevSecOps tools (as currently defined by the market). There was a lot to like about it, and they are moving forward into the future of “find all vulnerabilities, all the time”…except that there will be new vulnerabilities that are not so easy to spot once we get there, and our journey will be and will continue.

Lately, I’ve had the pleasure of delving into app and API protection, which I can’t (actually, not sure if I can or can’t, so I won’t) much at this time, but it’s also progressing in the same direction, if It wasn’t the same way.

As a developer, feature flags have caught my eye since they first came out.

They sang the Sesame Street song with me: “One of these things is not like the others.” Feature flags are… an advantage.

When they first hit the scene, developers were literally writing #if and #ifdef statements in their code to turn the bits on and off at compile time. It doesn’t remind me of something like a Seinfeld episode where they explain to the executives what the show is about. “A developer doing his job…this is a product!”

The market has come a long way since then. But, frankly, I don’t see these as standalone products. Take a look at the breadth of things most products do these days – CI/CD tools, either from the two markets I just mentioned or any other market in a similar place. Feature tags are still about “Turn this function off, then back on”. Newer iterations allow this without completely rebuilding the application. But it doesn’t exist with the scent that today’s gadget markets offer.

My opinion is that these tools will end up as part of a larger toolkit. Microsoft, Atlassian, and Cloudbees (to name the ones I’ve seen without seriously considering) are already implementing feature flags, shrinking the available market. And they implement it because it fits perfectly in many markets. DevOps Tools – implemented by both of these vendors – is one of the best markets it fits in.

Which market will they end up with? I have no idea, that’s part of the fun as an analyst. A better fit on the surface would be DevOps toolchain systems like Atlassian Offerings, where no matter what your toolchain is, you can use it to speed up acceptance testing or save the release without re-release. But I can make valid arguments for other sites as well, so I think you’ll all decide whenever options are available – decide with your money, ie.

Watch out for that. I’m not at all saying “Avoid premium label companies because they’re not a real product!” I’m just saying that your feature tag vendor will likely become part of a larger solution at some point, so make sure you have a plan to get out of it in case the bigger solution is something your organization doesn’t want to do deal with.

I A.m By saying, “If you don’t have a feature tag solution—even a local one—it’s time to put it in place. Being able to say “Oh, yeah, this feature screws things up, let’s stop it quickly!” is huge. For larger subprojects that take several races , the ability to get the correct code in the stream with regular check-ins, but is flagged off versioning is also huge. No merging or other insanity, just “BuildNewFunction=FALSE” in the source or config file. The more advanced the feature flag system the better – the newer can turn things on and off using an environment variable from the dashboard.This makes embedding the feature flag icon much easier and more intuitive than the “Have we factored in a database update not happening?” of the wraparound solutions It’s still not perfect – because that’s a journey – but buying at the store is now better than anything you’re likely to spin by hand.

And it kept swinging. Tokens or not, you’re building systems that power the world – or at least your own corner of it – and you’re not getting the recognition you deserve. So again, thank you. For all those people who don’t even know they are Must Thank you all.

Leave a Comment