Feature Control with A/B Testing and Validation
I believe this should be called feature control and validation/testing. That is the goal you should be trying to achieve with it. You gain control over your features independent of your deployments, decoupling them and with this you gain the ability to validate and test features independently as well. Which each on their own is a huge gain but put together creates great value for everyone in your organization. Like micro services allowed teams to independently deploy which allowed them to work at their own speed. This uses that same concept but at a feature level allowing a person or team responsible for a feature to control it independently of deployments and not have to rollback if they would like to remove a feature. I can also allow features to be rolled out at different speeds and be visible to different user groups.
The other large value is the validation and testing of different features either one their own or against other features to find the best option. This allows for far more freedom and many more ideas to make it into production. The worst thing that could happen is a great idea is discussed by the team but never implemented because it’s not seen as the best option by the people in the group. This bias has clear limitations while allowing for more ideas to actually make it into production and get real feedback can have a large cumulative effect on the end product over time.
For myself the roll that such feature control plays in a fast, consistent and safe deployment process as key. Most descriptions about continuous integration and continuous delivery seem to leave out the part that feature control can play in mitigating and alleviating a lot of the worry and fear that might come with continuous delivery and the lack of control that could happen without feature controls.
Feature controls can also play a large roll in ensuring the stability of core features of your service. This can be done by controlling when expensive features are turned off to open up resources for other more core services. Say you have a massive spike in traffic and a new or existing feature is nice to have but uses a lot of resources while under normal load this could be considered good but under high load this could be turned off. Allowing your core functionality to stay up and your service to continue to work for customers. This also applies to usage of third party services as well. Say you rely on a third party api to show a small feature in your service, if that third party goes down for any reason you don’t want to show a broken feature to your customer especially when it’s not your fault. So you simply turn that feature off and your service continues to present all your working features until the third party comes back online. Then you can turn that feature back on again. Using feature controls also removes a lot of the stress from these situations as you have a simple and consistent way to control these things. You don’t have to rush out a patch that might cause more problems itself or figure out some other solution while in the middle of a stressful situation.
It also plays a key roll if you begin connecting data and analytics directly to the feature release process. This way your team is less part of the final decision makers on a feature and more a group that can allow for contradictory and differing opinions to be tested and validated in production. This should also be seen as a blameless process. With the goal being to create a good set of possible implementations of a feature and iterating your way to a good outcome. The goal of the product managers or decision makers in this process should be to decide on the metrics the feature should optimize for and their weighting. Once that is defined the team can work together or individually as needed to create implementations and see how customers react to them in production.
This is where everything is tied together as you want this process to be as fast and tight as possible so you want a clean developer workflow good developer tooling that makes everyone productive, a good continuous integration to help catch any problems and ensure standards and quality are upheld and finally the continuous deployment and feature control so feedback and comparisons can be started as soon as possible.
A system like this should allow for developers to do what they actually want to do deliver value to customers and make a positive impact. Making that feedback loop as tight as possible and as frictionless and possible means people can see and feel the results of their work much faster than the might have previously.
