For many software engineers, the end-user experience is considered a key element of the features they develop. A number of studies conclude that businesses understand the importance of prioritizing customer experience to remain competitive, so this approach to development aligns well with these business goals. A recent Gartner study shows that 89 percent of brands believe customer experience to be their greatest differentiator. To manage against these expectations, software developers have always used tools and methods to control the programs they write, flagging areas of concern via configuration options or flags.

Techniques like preprocessor macros were commonly used in the 1980s to configure code paths and enable experimental features. When continuous delivery took off around 2010, teams began using more agile methods to support incremental deployment into production that don’t require changes in the codebase.

Companies that proclaim they are “customer-centric” and “innovative” still need to monitor key business metrics such as conversion rates and changes in engagement with each release. However, demands for faster development, iterations, and rollouts change the way we approach the process. Methods of monitoring and flagging that were well-suited for the longer development cycles and massive releases of the past no longer work for the rapid and ongoing cycles we see today. Successful software engineers will move toward a more iterative and experimental process — feature flagging — to gauge feature performance, effectiveness, and how well customers receive changes in real-time.

Feature flags present a more modern approach to rollouts and an avenue to accelerate software delivery. It presents an opportunity to learn from users throughout the cycle and create business outcomes with minimal risk.

Businesses Can’t Afford to Wait for Feedback
If customer experience is the most important indicator of success, then learning about an issue with that experience through customer feedback is the worst-case scenario. The reality is any rollout comes with its share of risk from customer complaints to financial loss. One study shows that a single hour of downtime costs a business $100,000 on average. If not done properly, the issues that result from a feature rollout can be far-reaching to a broad set of stakeholders and cause headaches for developer teams left scrambling for answers about the source of the issue. We know customers have limited tolerance for issues like application downtime or slow load times, so the time lost between a problem occurring and identifying it can be extremely damaging to a brand and directly affect the bottom line.

Following more traditional monitoring and flagging methods, a team of developers may only receive a notification of an issue after a large amount of the user base has been affected. By monitoring the rollout and tracking metrics along the way, we can learn of potential problems well in advance and minimize the blast radius of any negative impact.

IBM’s Systems Sciences Institute found that the cost to fix an error discovered after a product release was four to five times higher than one uncovered during design. Rather than spending time and cycles trying to identify the source of the issue or the timing of the event, experimentation through feature flagging allows developers to pinpoint the moment and impetus for the change, and if necessary, pull back the software update immediately to minimize the impact on the customer experience.

Mitigating and managing these risks throughout the process means developers can dedicate the time previously spent diagnosing, improving or repairing features that customers want most — all while avoiding downtime.

The Importance of Real-time Information
To match the pace of the business, software developers require the ability to write and edit software throughout the process and base those decisions on data. Feature flags and experimentation provide the data needed to assess the success of feature changes with statistical accuracy.  Experimentation evaluates the movement of engineering metrics and relates them back to the feature changes impacting them through sets of real user data.

This approach provides a safety net of sorts and a layer of control to the process. Through simple conditionals, developers can control which code is executed, and to whom. Arguably even more important is the ability to roll back features or updates immediately in the event of an issue, and without disrupting the user experience.

Understanding these changes in real-time presents benefits for a multitude of stakeholders, including the engineering team, business leaders, and most importantly, that precious customer base. Experimentation limits the exposure to poor-performing application features and minimizes the likelihood of a poor user experience. By taking an incremental and experimental approach to new feature implementation, a business can actually roll out new products and features more quickly, securely and effectively, as well as mitigate risk by allowing teams to release new features in a way that is secure, highly targeted, and measurable.