The Days of Feature Flags as a Niche Tool are Numbered

Almost every disruptive enterprise software technology starts as a point solution and over time finds a home in a larger platform. It doesn’t matter if it's developer tooling, observability, or IT service management (ITSM). Eventually every point solution finds a natural platform home. Before I dive deeper into flags, let's look at observability as a historical example.?

A decade ago application performance monitoring (APM), infrastructure monitoring, database monitoring, and end user monitoring were all point tools. There were even niche solutions focused on just virtual machines, middleware, and other narrow areas of focus. Technology like APM was typically adopted for a small subset of business critical applications at the team level, and not considered a shared service.?

Today you will struggle to find niche observability vendors, and even if you had a unique idea for lets say database monitoring, the chances of that idea getting significant venture capital backing are low. Today platforms like Datadog, Dynatrace, and AppDynamics negate the need for organizations to cobble together niche point tools.?

APM is no longer a point tool for a few apps, it's part of an enterprise wide observability strategy.

Continuous Delivery and Feature Flags are a different means to the same result

Let's go way back into ancient Harness history, back to 2018 when Harness was just continuous delivery as service. There are really three main value drivers for organizations looking to adopt continuous delivery:

1. Increase Velocity
2. Reduce the Risk of Change?
3. Improve Developer Experience?

Continuous delivery makes it easier for developers to get code to customer faster, and unique Harness capabilities like continuous verification dramatically reduce the risk of change by using ML to judge the quality of a release, and rollback automatically. As a result of improving velocity and reducing risk, the developer experience naturally improves as developers can focus more time on innovation and less time on toil such as: maintaining pipelines, baby sitting releases, and debugging incidents.

Now let's look at feature flags. By encapsulating new changes behind a flag, you increase the velocity of innovation by giving developers the freedom to experiment in production. Progressive delivery with feature flags gives product teams the ability to incrementally roll out new functionality, and rollbacks are simply a toggle.?

Ultimately developer experience is improved by increasing velocity, reducing the risk of change, and getting them out of the business of firefighting incidents. Sounds a lot like the benefits of continuous delivery?

Feature Flags is no longer a Niche

Historically, most investment in feature flagging was done at a project or group level. Usually a customer facing business critical app that needs experimentation, progressive delivery, and maybe the ability for customer success team members to change configurations on the fly.?

As flag adoption increases, the idea of each team having their own flagging tool starts to increase complexity. It's not unusual for one team to be using a flagging product, another using something homegrown, and a 3rd team using database toggles all within the same enterprise.?

Governance and supportability then become an issue, as flag usage starts to increase and you end up with stale flags, different naming standards, and bespoke processes between teams. Ultimately the tool you brought on to improve velocity and reduce risk, is now a liability. Knight Capital is probably the best example of feature flags done wrong.

Platform Integration is Answer?

Ultimately when you look objectively at the benefits and risks of introducing feature flags into an organization there are 5 things that stand out:?

1. The value drivers of feature flags and continuous delivery are the same?
2. There are massive benefits in having a CI/CD pipeline that natively supports feature flagging as a stage?
3. Feature flags are at the point of maturity?where it makes sense to have an enterprise adoption strategy as a shared platform rather than point team usage?
4. There are lots of benefits to unifying CI/CD and Feature flags from a governance and security standpoint?
5. Lack of standardization, governance, and best practices can actually lead to more developer toil and risk with flags than without?

In summary, feature flags and continuous delivery are a different means to the same result, and there are significant business benefits to unifying flags and CD as a comprehensive software delivery strategy. Feature flagging is a capability, not a company.