How Compass Is Embracing Feature Flags for Development

Real estate can be a complicated business, with multiple stakeholders and a continuously changing landscape. That's the market that New York-based Compass is tackling with an evolving software platform to help brokers, buyers and renters.

With such a rapidly changing environment, Compass has found a need to deploy capabilities with feature flags. Embedded into application code, a feature flag enables an organization to launch a new capability in a gradual rollout to test stability; it can also be rolled back if anything goes wrong. The feature flag approach is part of a broader software development methodology known as progressive delivery, where new functionality is delivered in a continuous process.

In a developer meetup on March 26, Lucas Reis, senior software engineer at Compass, detailed how his organization has embraced feature flags in a scalable approach.

Starting with an Experimental Approach

"At Compass, we build tools for real estate agents and their clients, and we have tried to make this process less painful for everyone," Reis said.

Compass currently has approximately 88 applications that are powered by 309 different services. In February 2020, Compass developers did between 110 and 160 code deployments a day and have fully embraced the progressive delivery model, he said.

When the company began using feature flags, it built its own, custom in-house tool, called the Experiments API. While the effort did work, it was somewhat limited. On an enterprise-wide scale, Compass had some problems that required more intricate rules than what Experiments API could enable. For example, it couldn't handle a progressive rollout from the East to the West Coast. There was also a desire by developers to automate A/B testing for product launches to determine the best option for a given feature, Reis said.

In addition, Compass didn't want its developers focusing their time and efforts on the Experiments API; rather, management wanted the focus to be on the company's core products, Reis said. So Compass looked for a commercial tool. It ended up choosing Optimizely, he said, because it's a popular tool in the space and developers at Compass had previous experience with it.

Implementing Feature Flags at Scale

With the Experiments API, Compass had only done a limited amount of feature flags in some small groups. With Optimizely, the goal was to roll it out across the enterprise, and that required some education.

"We needed to understand together how to do feature flags," Reis said. "So we had a lot of planning sessions and engaged in mob programming."

Mob programming is a very engaged, interactive and in-person approach to coding. About 70% of the code that Compass wrote with the approach was done together in the same room, with developers all looking at the same screen, he said.

From a scalability perspective, Reis said it just wasn't feasible for Compass developers to install feature flag functionality directly in every service. Instead, they opted for enabling a feature flag-as-a-service approach where the various services call out to a centralized service to enable scale.

Four months after the decision was made to move to Optimizely and fully embrace feature flags, Reis said feature flags are now part of five back-end and 17 front-end projects, as well as two mobile apps.

The Challenges of Building a Culture of Experimentation

At the core, feature flags are all about enabling experimentation. Reis said that within Compass there were many teams that were excited about the prospects of actively experimenting with features, but there were skeptics as well.

Reis recommends that project managers and development team leaders seek out the early adopters within their organization because they will be key to helping advance the adoption of feature flags.

"They will not be mad with small errors that will happen, and they will help you," Reis said. "Then you can reach out to the late adopters with some success numbers from your early adopters."